Five kinds of technical debt

Martin has described a concept called Technical Debt and this seems to have entered the vocabulary of our projects. It is a useful term but I worry it is being abused somewhat.

It seems that the term is being used to described a multitude of evils. I've found it very useful to try and categorise the different kinds of debt. In fact I'd go further: I think it is dangerous not to understand the type of Technical Debt we are dealing with and, even more importantly, what the root cause of the Debt was (or continues to be).

The other thing I've seen with technical debt is that can be transparent or opaque. Transparent debt is 'on the books' so to speak, we incur it knowingly and the team and the client are part of the decision. Opaque debt is off the books, either developers don't realise they are incurring debt or the team decides, for whatever reason, to hide the debt from the client.

Anyway here are five different kinds of "Technical Debt", I'm sure we won't all agree with this list and it certainly isn't meant to be exhaustive but I do think there is merit in better categorising and understanding these issues:

Ignore
Skip doing something we know is really needed. So take a quicker path ignoring, say, the need to build something horizontally scalable. Of course there are sensible ways to do this, such as splitting a story into two parts and playing another part later. Unfortunately this doesn't always happen, instead developers sometimes take a unilateral decision to ignore a requirement and hence incur debt that is not visible to the team as a whole (at least not until later). I've heard people use 'yagni' to justify this behaviour.

Get Surprised
Your client comes up with some new requirement that means a change in direction we cannot easily accommodate with existing code. This often shows itself as a 'code base of two halves': pre and post change of direction. We may live with two ways of doing things in the code base and this might never become debt at all, or at least not until some cross cutting requirement forces the issue.

Disregard some data
A classic example of this is build time, or more specifically the time it takes to run all the unit tests. Projects teams often see this time starting to creep up but it gets ignored until such time as it starts to really impact productivity. They are slowly incurring more debt and as is the nature of debt the longer you wait to repay it the tougher it gets.

Repeat a mistake
We incur Technical Debt, often without even knowing it, when we repeat previous mistakes. The one I see the most is Hibernate hiding from the developers that there is a database is involved, to the extent they forget about the cost of a database call. I think this one could also be called 'ignore advice'. Either way we storing up trouble.

Guess
This usually happens in relationship to a non-functional requirement, such as performance, and again it is largely hidden incurrence of debt. Basically we just guess that something will work as expected and don't bother to check , we just assume it will be ok. It is easy to avoid guessing either by using a spike or just a 'back of the envelope' calculation.

And finally...

Phantom Debt
This is 'technical debt' as invoked by a developer who has decided they don't like part of the code base and hence want to rewrite it. Technical Debt certainly sounds better than 'egotistical refactoring session' ;-)

(Many Thanks to all my colleagues for the internal discussion and feedback I got for the first version of these ideas, no doubt we will continue to argue about this)