What is technical debt? Let’s look at an example. A developer is coding a new feature into an existing platform. As is often the case there’s a time constraint and the work has to be completed quickly. To meet the deadline the developer cuts a few corners. Nothing drastic, nothing that would be visible to the user, but a few small things. The data access isn’t as efficient as we would like, there’s not much in the way of test coverage, there’s a few ‘magic numbers’ in the code. At first these were only minor irritations, but over time these little shortcuts build up, until they make it harder than it would normally be to complete a new task. Because the data access is inefficient it runs slow at scale, making it harder to add new features with acceptable execution times, the lack of test coverage means new features spend longer in QA, those magic numbers add days to solution design, while we figure out what they mean and if the new functionality needs them to change. Don’t forget that we’re still under time constraints so all the features we’re adding now need to be done against stiff timescales, so we’re looking for ways to cut corners on a system that is already suffering from having its corners cut.

In the end progress grinds to a halt and, reluctantly, we rebuild the system and start the process off again with version 2.0.

How can we prevent Technical Debt having such a huge negative impact on our products and businesses?

There are three things worth thinking about. Firstly Designing for Modification. Most software is, at least in part, obsolete at the point of delivery. While we were building it things changed, new requirements emerged. There’s always something that could or should be done to the system, even on it’s go live day. Bear this in mind when designing it. At every opportunity ask how easy it would be to add features or change rules. Create project specific coding standards that explain how to make changes and include in them expected timescales for making these changes. This provides some protection from downward time pressure. The proper use of Object Oriented Programing techniques can be a lifesaver here – just as the improper use of them can lead to disaster. Designing for modification is one of the most important aspects of system design. It’s right up there with User-Centric Design, Design for scale and Defensive Programming. It’s also the most commonly overlooked. If you are lucky enough to be starting from scratch the one piece of advice I’d give you is to include this in your thinking. A platform is for life, not just for Christmas.

The second thing worth mentioning is the ‘Technical Debt Register’. This is a technique we found very useful both for clients whose systems were riddled with debt and also those starting afresh. The register tracks each individual piece of non-ideal coding and puts a time value against it showing how long it would take to fix. Then, when that piece of debt causes an issue for further development the additional work is tracked as ‘Interest’ on that debt. The interest will keep growing until you pay off the principal and you will be able to see what effort will be required to pay that off. This can be a very useful planning tool and can highlight when paying down the principal debt would actually be cheaper than continuing to cut corners. 

Technical Debt Registers are easy to create if you start when you’re first building the system. Creating them for existing systems is harder and as a rule of thumb you should allow a full sprint to create it. Given that high Technical Debt is often a symptom of time constrained development it can be difficult to convince people that a sprint just to make a big spreadsheet of what’s wrong, write the solution as stories, cleanse and estimate them is a good idea. It is, if you want to avoid diminishing returns and platform rebuilds.

The final thing worth bearing in mind is that that technical Debt is unavoidable. It’s not a symptom of bad development, it’s an inevitable consequence of changing requirements and business needs. All systems carry some. If you have a register you can decide what level of Debt suits your needs. There are things you may decide never to fix as the ‘Interest’ on them is low. If you were fortunate enough to be able to Design for Modification then most of your debt should be low interest. Technical Debt won’t kill you, unless you ignore it.