Subjective Codebase Health Parameters
Debt is a property of any system. It allows the system to keep functioning in times of crisis by borrowing resources from the future to compensate for today’s shortcomings.
The more debt there is in the system, the harder it is to work with it. It takes effort to keep it under control. The more you try to reduce it the harder it becomes to further reduce it. Attempt to maintain it within a healthy range but don’t bother optimizing a property that follows an asymptotic path.
Plenty has been written about how to measure technical debt by assigning a value on a scale to anything that can be attributed such thing. There are one too many strategies suggested by consultants on how to deal with the most generic of the problems as if those are the ones that are going to make or break your codebase.
Both measurements and strategies are focused on the code. The easiest thing to blame. It never argues back. The coders are almost always left out of the equation yet they are the ones who influence the debt property the most.
What if what constitutes technical debt for one team is the best solution another team has come up with to in order to speed up things. What if a small teams can take a more direct approach to problem solving because there is not that much turnover. What if everyone knows when they can stomp the ground and when they have to tiptoe.
One team’s approach to handle a property of the system, the debt in this case, is totally different from others. Software is there to solve specific problems and to adapt and evolve over time to match the business needs. It should not stand in the way of doing business in the same way hardware does.
To manage the technical debt of any codebase, you have a better chance to identify the real bad code from the people’s reaction when they have to work with it. How many times does your team mates roll their eyes when they have to work on a given component? How many times do you bang your toes on the corners because you are in the dark? The amount of sighs per minute is a good indicator that there are too many unknowns. “Aha!” moments are tricky ones, it translates to “Yay!” for juniors and “Really!?!?” for seniors.
These are all indicators that you and your team maters don’t have the situation totally under control and it might happen that in times of crisis there might be a moment panic caused by the lack of one’s ability to solve the problem at hand due to the inability to even define that the problem might be.
The good thing about technical debt in software is that it rarely matters. And even when it starts to matter it is cheaper still to just add more power rather than taking resources from improvements and features development.
The only time the investment is worth the effort is when the codebase is a hotspot for changes and hinders the development of new features. How much harder is to adapt to change because of that debt. When you are constantly adding extra time in your estimation just in case you have to also interact with certain component it’s time to tackle and reduce the debt to a manageable amount.
Tackling debt and keeping it under control is a task belongs to everyone on the team, from the beginner to the master. Make your case, pay it off. Keeping delivering new features and improvements at a fast pace. And when the time comes that you need to take on debt you will have plenty of room.