I am glad you are here! Let’s talk about decluttering. The straightforward explanation of Decluttering as per Google is getting rid of stuff you don’t need or use anymore. For me it is a lot more than letting go of items. For me, it changed my perspective of looking at things and life. Below is an outcome of my learning from the decluttering process I went through last year. Letting go helped me to make new space, gain revenue, and have new energy! For a healthy lifestyle, it is important to identify things that are not serving you and declutter them. Decluttering my material belongings last year made me wonder if this same process could be applied to code.
While researching I found that when you have a system with a lot of old code - maintenance of the older applications typically consumes more of the technology budget. Companies which hold on to the older system and fail to declutter set themselves up for negative business impacts. These can include higher operational expenses, reduced performance and scalability, takes longer to take the product to the market, and have more customer issues. Clutter doesn’t only happen when you fail to update older systems. Clutter can also happen by writing more code than needed. When working on new features consistently takes priority over the minor issues in our code that pile up as tech debt, we might be setting ourselves up for a pitfall.
Here are a few more reasons why we should declutter our code:
- Decluttering brings clarity: Just like how a clean desk can make you feel productive, working in a clean codebase can bring more clarity to your vision. Having code that is easy to follow means that the same code will be easy to add to. Imagine yourself working in an API which follows coding standards, has a clean thoughtful architecture, and follows good testing strategies. It then becomes very easy for you to scale upon it, reuse or redesign if needed when you have that clarity.
- Cluttering could be costly: Imagine yourself modifying code written ten years ago. Now, before you make any modification to that you would need to put time into researching it. You need to know all the systems connected to that piece of software and find out why that logic exists the way it does. Going through the documents (if they even exist) and knowing all the parts connected to it just to know the logic you are trying to refactor is not even needed. So, that is not fun! Old and cluttered systems and codes are hard to evolve. Small changes in cluttered code mean a lot of regression testing, manpower, time, and energy. This also means small changes will cost you more money than expected which could also increase the chances of losing stakeholders' interest.
- Optimizes technical budget: From the previous data we looked at, this is the obvious reason not to clutter. It would cost the company a ton of its technology budget. So using the old legacy system, unpolished code could sometimes lead to shutting down of the company.
- Helps onboarding teammates: It is easy to ramp up a new teammate when you have only a few specific technologies, codebase, languages, or techniques involved. Similarly, it would be easy for that teammate to grasp the situation and contribute to the codebase when there is less complexity in architecture. It helps them feel good about joining the team and making an impact, increasing the chance of retaining the employee.
- Easy to maintain: When there is less cluttered code with clean logic you could refactor in one place and be confident about it. Also, infrastructure, tools, networking systems if they are up to date, it is easy to upgrade them and keep them maintained versus waiting till they fail on you.
- Incomprehensibility:
While working in your codebase, the following things are telltale signs.
- the system entertains more complex techs than it needs
- it is getting harder for you to ramp up a new developer in a strategic manner
- find yourself going into rabbit-hole most of the time to add a fix
Most of the time bad design encourages you to further bad design or sometimes forces you to extend on it. For example: When you only have a week to add a feature, your instinct would be adding code on the same existing base project versus fixing the whole structural problem. - Code problem: When you have a problem with a bad top-level design it syncs into down to the code -level. Things like no common coding standard, naming convention, or organized file structure adds up to the ambiguity. It is another sign of a cluttered project.
- Lack of maintenance: This is the red sign! When you see a framework and libraries in the project not upgraded or maintained for a while, speak up. This normally means adding a bunch of debt, the possible introduction of bugs due to old libraries, more coding time as old libraries would not be as advanced as the new one and lack the cool features.
- Unclear requirement: Most of the time unclear requirements are an issue of foresight- when the requirement is not clear and changes on you every now and then while adding a feature, you tend to add/delete/refactor the same portion of the code multiple times. Your code architecture and design will get cluttered eventually as meeting these new requirements means adding a few uncalculated components or pieces in the system.
Identifying Signs of a Cluttered Codebase
In the decluttering process, the first step is acknowledging the clutter is bad. The second step would be identifying the signs that you are heading toward the cluttered system. Here are a few warning signs which signal to the code clutterings:How to declutter your codebase
Now that we’ve talked about a few reasons why we should declutter, let’s talk about how to do it! Here are a few ways to declutter a codebase:
- One to one function This idea elaborates that when a single logic is assigned to one function- it has one thing to do and it does it well. While designing, if we are performing a few logics in one function, let's revise it and extract the logic and put it in a different method and organized file.
- Proper function names Function names should be concise. Ideally, the name suggests clearly what the function does, without the necessity to dive into the implementation details. Having a few coding standards in place, conventions, and file patterns would help a lot. To keep ourselves on track we can use camel case format that starts with a lowercase letter: addItem(), saveToStore() or getFirstName().
- Avoid repeating code Refactor and reuse should be the main mantra of the cluttered-free code. If you see a piece of code and have a similar component hanging in your codebase but you need to add something, do not copy paste and modify it. Whenever you have a doubt, refactor the code. Refactor so it is reusable and scalable.
