Sharing Our Passion for Technology
& Continuous Learning
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.
- the system entertains more complex techs than it needs
- 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:
Cohesion is an indication of the relationship within functions in your class. While designing you should strive for high cohesion, it is better to have all single responsibility principles in a class to maintain cohesion. When designing your structure remember that classes that have higher cohesion are easier to maintain.
Coupling is an Inter -Module Concept. It is the degree to which one class knows about another class. While designing you should strive for low coupling i.e. dependency between classes should be less.
Big functions that have a lot of responsibility should be avoided and split into smaller ones. Big black box functions are difficult to understand, modify, and especially test. Easy ways to keep ourselves on track would be keeping it small. Here are a few ways you can ensure your functions are small enough:
- 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.
Think before bringing in something in your system: Remember the left-pad incident when a simple single module from the npm got deleted and it broke the javascript ecosystem. So, even though we do not want to reinvent the wheel and refrain from adding everything from scratch, it is also important to research thoroughly and make a conscious decision before bringing in third-party libraries and frameworks.
Although we don't like frequent requirement changes, our code evolves and they do change on us. Some libraries we imported a year ago might not be needed anymore or be outdated. Before adding a new library to the codebase, give a good look to the existing ones - can you upgrade the existing libraries or reuse them in some way? If not, delete them.
Try not to jump straight to solving the problem. Ask a question to the business or yourself, "What is the problem we are trying to solve?" Sometimes that question can result in a total 360 change in the feature. Remember people pay for the product to solve the real problem. So try to find the real problem, and try avoiding code clutter in an attempt to solve a problem that might not be a problem to start with.
Technical debt management has been one of the core software engineering practices.
Adding technical debt by avoiding the scalable strategies to gain some time is always the wrong choice for the software industry. Track the tech debt if you cannot refactor the code during your sprint work. There are some situations when you cannot skip the technical debt. In those cases, at least track the debt. Track the debt in the backlog, add a task, create an issue in the repository, etc. This makes sure that we do not forget about it and lose the companies revenue in the future.
We know how to write code and write code to solve the problem with the best interests in mind. Sometimes we do miss a few things here and there, which adds extra pieces of logic in our solution. This can be solved by embedding analysis tools in our code, tools like SonarQube, DevBug, flaw finder which are open source and available to us. These tools will run the analysis on our code to make sure we have secure and clean code before getting pushing into production. Obviously, these analysis tools are not as smart as developers are, so the idea here is to make them work before developers do! Let it run before code reviews so we know our code is clutter-free.
