Every growing codebase in every industry is accumulating technical debt. The consequences of excessive technical debt are low productivity, high rate of errors, delays in delivering updates, higher costs, overburdened developers and less happy customers.
Since technical debt is inevitable, like death and taxes, the question is how to best manage its accumulation and reduction, and how to keep it at tolerable levels that will not result in bad business outcomes.
Before exploring solutions, exactly what are we trying to solve for? There are multiple definitions of technical debt, and here I quote three:
I particularly like the kitchen metaphor in that everyone in the organization, not just developers, immediately understands the problem and the consequences of doing nothing about it.
Erik Dietrich writes on the NDepend blog that the one thing every company can easily do to reduce technical debt is to measure it.
“Generally speaking,” says Dietrich, “focusing the spotlight on something can, in and of itself, alter the thing you’re looking at. We might borrow from physics and think of this as “observer effect. … If you want to improve something with any efficacy, you must first start measuring it so that you have a benchmark. Thus shining light on something represents a possible improvement strategy in and of itself, as well as a first step ahead of other interventions. It is for this reason that I think of measurement as ‘step zero’.”
It is therefore important to measure it so that you can later tell if this is getting better or worse. You can perhaps wing it for a while, but metrics are the best starting point.
There are different approaches to measuring technical debt. A good approach is provided by Patroklos Papapetrou in his post How to Calculate Technical Debt and Express it Clearly, but the bottom line is that you need to know the amount of effort necessary to eliminate the debt in relation to the total amount of effort invested in the creation of the code. “Both man-days and ratio metrics should be used by management and development teams in determining their strategy for reducing technical debt because each of them answers a different but equally important question,” says Papapetrou. “For man-days, the question is what is the effort required?, whereas for the ratio it’s how good or bad is the code quality?”
You will be tempted perhaps to change your processes, modify your culture, talk about the importance of technical debt at length, bring in experts, but I suggest that there are three easy steps that will radically reduce technical debt beyond step zero.
Here is the first thing to keep in mind in order to reduce the debt. Don’t obsess over tools and techniques that will probably fail to change working habits. Look at how people work and figure out how you can introduce simple, non-controversial steps that will create greater clarity. In particular, rely on better communication within the code, which is the second best disinfectant. Documenting code should be the natural byproduct of the communication that needs to happen among team members already. Think of it as being at the airport, alert to what’s around you: If you see something, say something!
Developers need quiet time to concentrate on writing code. But both the physical and virtual environments have become more noisy and more demanding of our immediate attention. Tools like Slack and Hipchat are useful and can help resolve certain issues quickly and painlessly, but they also tend to be overused for all kinds of trivial things that break your concentration. If particular, those tools are just not designed to collaborate on code. So if you want less technical debt, stop paying attention to the noisy posts in your Slack or Hipchat feed. Mute all that activity and concentrate on writing good code and communicating about the code with your development team using solutions that are largely free of noise.
Your development team probably gets together on Mondays and decides what will be accomplished that week. Then everybody goes to work on their assignments and when Friday arrives the team gets together and reviews what was accomplished. You probably had questions and comments along the way you could have addressed, but who has the time to cut and paste code snippets, explain the file, version, line number, find the right person to share this information with, and so in order to ask a question? If you want to reduce technical debt, you must find a way to communicate at the right time about any lack of clarity in the code and any approaches that you find will require re-work. If you take any shortcuts today to make the deadline, inform the team using the whatever method is the easiest and most effective, but don’t put it off. You and your team will want to come back to this debt when the time comes to ensure the dishes are not overflowing in the sink, and it’s best to alert everyone in the code itself, while the concepts are fresh.
Find solutions that keep you focused on the code itself, not switching context, and not getting distracted by the latest lunch pix.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Please share your thoughts and feedback @teamcodestream.
CodeStream helps development teams discuss, review and understand code. CodeStream links comments and issues directly to the code blocks they refer to, making them instantly available to everyone on the team.
Your team knows a lot about your code but the knowledge is locked inside the heads of individual developers.
CodeStream helps to capture and share that knowledge, making your team happier, more productive and more resilient.