Code legacy is an inevitable topic in software, that can create a lot of frustration : "We must rewrite this part because it's too poorly coded and unmaintainable, but we don't have time!"
The problem is generally that the actual deciders undervalue the issue or don't see it at all. Imagine the lobby of the main building being cluttered by a pile of trash, growing every day... Would the boss allow time to clean it?
Cleaning existing code is called refactoring. During refactoring, developers rearrange the code in a nice way so that it is more readable, more maintainable, and often more performant as well.
Refactoring should be a common word in any software-related business or product. It's a normal activity. It is like washing your hands in a hospital or watering the plants in a flower shop. As a CTO, I request at least 20 % per week to dedicate to it.
I consider 3 levels of refactoring:
On-the-fly. The refactoring is tiny and related to another task (or card or ticket depending on the terminology). It is done while coding that task, potentially inflating the estimation of that card.
Refactoring task. The refactoring has been identified in a previous work and been exposed to the management team. It is extracted as another task, estimated and planned like any other task. That fits well in the 20% quota.
Refactoring projects. Sometimes the refactoring will impact many different sections of the code. It cannot be isolated as a task so it becomes a project. Like any other project in the company, it will be divided into tasks, estimated and scheduled accordingly in the 20% or more if it meets more directly product expectations.
Refactoring projects
Refactoring projects are the riskiest because they compete with regular project in terms of time and effort. In short, they will probably need more than the 20% quota and mobilise management for a while. At first, many tasks will create no visible and cost money. That's why it is important to compartmentalized them as much as possible, reduce the scope and sensitize product and business deciders of the long-term outcomes.
The situation is critical because without refactoring any new development will actually increase the technical debt: more unexpected bugs, harder-to-maintain code, more desperation, less attractiveness for the developers. It has to be done.
This needs tech leadership. If the important refactoring do not occur because "we don't have time", then it's a tech management issue. Sometimes developers can use the "time" argument as an excuse. It's worth digging: the refactoring could be delayed (it can wait a few more months/years), is smaller than we though (or bigger!), developers just don't have the right coding practices or are not skilled enough to maintain an old and big code stack. In all of these cases a great deal of attention is required by the tech management.
"The big rewrite"
The big rewrite consists in rewriting entire part of the business' code. It sometimes sounds like the best option, especially to (junior?) developers. "If only this was coded like this since the beginning...".
It's a trap!
It is extremely rare that TBR is the right solution. Even "hopeless" situations can be turned into smaller projects, from basic code rearranging to re-architecturing. Then little by little the code will be refactored, without interrupting the business and losing enormous amount of time & money which is usually the case with TBR.
That is only possible with a higher-level technical analysis, typically done by the CTO with the help of developers, a very good organization and an excellent communication:
- what is included and excluded for each step
- what has been done after each iteration
- how difficult the current step is and how to restructure next steps.
- ...
The tunnelling effect is dangerous here and must be monitored carefully.
Code legacy is also good
I would like to conclude on a positive note : code legacy is also a good sign. It means an organization has built something and used it for the business, most likely with limited time and resource. Identifying code debt means a progress in coding expectations and business strategy as a whole.
The legacy defines who we are as an organization, what we have been through, what decisions were good or bad. One who reads the legacy will learn a lot about the business past and present.
Top comments (0)