Refactoring is an investment

Writing clean code is not something to take lightly. Of course, There are some cases where you need to push to production a quick (& dirty ?) solution. But most of the time, in an enterprise environment, you need code that is maintainable, modulate, easy to evolve, that is agreeable to work with.

The drawbacks of an improper codebase are very often underestimated:

• Depreciated reading and understanding: We know that as developers, most of our time is spent reading code to modify it, solve bugs, add new features, etc… So having an easy to read and understand codebase is extremely important. Otherwise, the complexity will keep on growing exponentially, and the time wasted to understand something that could’ve been simpler will accumulate.
• Increase the likelihood of bugs and the debugging time: A messy codebase significantly raises the probability of introducing bugs and extends the time required for debugging. When code is convoluted and lacks clarity, it becomes a breeding ground for errors. Developers may inadvertently introduce new bugs while trying to understand and modify existing code. Moreover, debugging becomes a daunting task in a poorly organized codebase. Identifying the root cause of an issue becomes a needle-in-a-haystack scenario, leading to frustration and wasted time.
• Impact on Team Productivity and Collaboration: An improper codebase will affect individual developers. Inconsistent coding styles and practices can lead to confusion and misunderstandings within the team. And also, a poorly maintained codebase can act as a roadblock for the introduction of new features or the integration of third-party libraries. Technical debt accumulates, making it increasingly challenging to adapt to evolving requirements and technologies.

Some solutions for that are pretty straightforward:

• Code Reviews to ensure that the coding standards are maintained by the group and stays homogenous
• Testing to validate new developed features, but also allows more secure modification of the codebase, whether it is creating new features, modifying existing ones, or refactoring.
• Refactoring regularly what stands out as improper code, sensitive one, to address any kind of technical debt early on
• Documenting can also be a good practice in some cases, to provide context about the why, but in my opinion it should only be done when the why is not intuitive at all. I am very much a member of the “The code is the documentation” team.