Are you heading up a software development team, or perhaps working as a CTO? Then you most likely have to deal with technical debt on a more or less daily basis. So how can you approach these issues in a structured way?
The phrase ‘technical debt’ was invented by Ward Cunningham, a software developer also known for inventing the wiki and co-authoring the Agile Manifesto. He came up with this expression as a way to explain to non-techy people why they needed to budget resources for refactoring. Today, the phrase is widely used within the software development world. An easy way to describe technical debt is to see it as the result of going for a quick, easy and imperfect solution – something you in the future, sooner or later, will need to spend time on to improve. A straightforward example is code of poor quality.
Know your code health
To get insights into code health, there are several tools available on the market. However, these often only give snapshots of your current code status. This could of course be valuable. But a simplified picture is also limited. It might not give a clear view of where it makes sense to focus your improvement efforts. In addition, maybe you have KPIs that require a certain amount of code improvements? To meet them it might be tempting to simply go for the easily managed and non-time consuming problems – the so-called low-hanging fruit. But of course, while this let you tick some of your to-do boxes, the most important issues may still remain. And continue to give you headache.
So, with a large code base, how should you know where to start? Or rather, as per the heading – how do you prioritize?
You want to look into where the hotspots are. In other words: where are the complex parts of the code, and where do developers spend most of their time? Keep in mind: a hotspot doesn’t necessarily equal a lot of technical debt. There may be a high level of activity in parts of the code when, for example, the team is working on new functionality. If that code is of high quality, this is not where you focus when using a technical debt perspective. It is the development hotspots with low code health that should go on top of your priority list. So when looking at hotspots, it is also important to ask yourself why your team spend their time on those particular parts of the code.
Getting answers to the questions above is usually both helpful and a relief. If you have used a tool to analyze your code, you get the insights you need in black and white. Unfortunately it is quite common that these insights lead to … not much at all. The result of the analysis – a report or something similar – is perhaps read, but not acted upon. It becomes a paper product (albeit in digital form).
Iterate!
The solution here? To be persistent. To iterate, and re-iterate. Because as you know, working with things continuously is usually a good idea. So make a new analysis after, say, three months. What happens over time? How has your code health evolved historically, and what direction is the code moving in? What are the risks with the trends you are seeing?
The principle of iterations, and looking into code health on a regular basis, mean that you can work in a loop: you manage the most critical issues, and next time you run your analysis you will – hopefully – see a positive trend for those prioritized areas. Which means that the next-in-turn issues now become top priorities. Every software development team is different, so there is no one-size-fits-all for how to best plan the work. But generally speaking, it usually makes sense to align with your ongoing development work – in other words, address the technical debt in the parts of the code your team is working on anyway. In case the risk of critical issues is very high, you might of course want to dedicate people to managing your technical debt.
An analysis of your code status doesn’t always present any major surprises or upsets. It is quite common that the development team knows, or at least suspects, where the problem areas are. But re-occurring analysis is a good starting point for cost-efficient management of your technical debt.
Want to learn more about how to create a sustainable process for software projects?
