Mark Needham

Thoughts on Software Development

Finding the value in fixing technical debt

with 6 comments

Technical debt is a term coined by Martin Fowler which we tend to use on our projects to describe a number of different situations on projects as Ian Cartwright points out in his post on the subject.

Ian covers it in more detail, but to summarise my understanding of what technical debt actually is:

Technical debt is where we know that something we choose not to take care of now is going to affect us in the future.

The latter part of the sentence is interesting because it is somewhat subjective. There are clearly different levels of what ‘affect us’ means.

Phantom Debt

The most interesting area of this is around the area of what Ian describes as 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’ 😉

Since reading Uncle Bob’s Clean Code I’ve become a bit fanatical in my approach to trying to make code as readable as possible, mainly by extracting code into methods which describe what is going on.

Whenever I come across code that doesn’t make sense to me I try to break it into methods which make it easier for me to understand and hopefully easier for the next person to read to.

I don’t think that’s technical debt in the typical sense because it is difficult to put a value on how that is going to hurt us in the future – I am only trying to make my life easier the next time I come across this piece of code. The problem is that it is my opinion that structuring code in this way is preferable. I have certainly worked with people who consider it overkill.

The benefits of handling this type of ‘debt’ are not as great as taking care of a concurrency issue which could cause the application to work in a non deterministic way when handling a high number of users for example. On the other hand the amount of time to fix it is much less.

Clearly if I went through the whole code base and applied this refactoring everywhere that would not be adding value so my approach tends to be that I’ll only refactor if I’m working with that particular piece of code and its current state is hindering my ability to do so.

This is fairly similar to the advice I have been given around the best approach to getting tests around legacy code – only put tests around that code when you have to work with that particular piece of code otherwise you’ll be there all day.

Looking at the value we’re adding

There is a bit of balance between making the code perfect and adding value to the customer.

One of the ideas of lean is that we should always look at the value that we are adding to the customer and in removing some kinds of technical debt I suppose we are not actually adding tangible value. I don’t think it’s completely wasted time though because we are (hopefully) helping to reduce the time wasted trying to read difficult to understand code, making debugging easier etc.

It’s definitely a tricky balance to find though.

Be Sociable, Share!

Written by Mark Needham

January 10th, 2009 at 2:04 pm

  • Ongoing maintainability is of value to the customer and the organisation but it’s hard to measure and customers never ask for it explicitly in my experience.

    Its value comes from reduced time to understand the software, less chance of introducing buggy code and from reduced code complexity. These all have direct benefit to the customer in terms of delivering a better product faster.

    We term the gradual build up of technical debt as ‘software erosion’. In my ‘When Good Architecture Goes Bad’ workshops ( I always ask the audience who’s responsible for stopping software erosion. Most people recognise that they themselves have a responsibility for this and that as technical people they need to make their managers aware that their software is eroding and somehow convey the size and effects of the problem. (This is a hard problem :-()

    I’ve just invited you to a Google group discussing the problem of software architecture decay. The idea is to find common examples of decay, find practices that help slow decay and come up with some tools for helping technical people convey the size and value of the problem to their managers:

  • Pingback: What kind of college degree should you pursue to go into the sales field of renewable energy? ? | The Solar Truth()

  • Pingback: Arjan`s World()

  • I’m pretty sure the term “technical debt” is due to Ward Cunningham. One important part of the analogy – one that I’ve often forgotten – is that debt can be a useful tool. I believe Ward has talked about the business having an aggressive goal that the team can’t meet in the desired time with its usual level of code cleanliness. In that case, the business – in conversation with the team – might rationally decide to take on a particular level of debt, *knowing that they’d have to pay it back with interest later*.

    When we talk about technical debt, we talk about it as if the interest will never be paid and debt will continue being taken on until the program becomes “bankrupt”. That’s certainly not uncommon, but the alternative of well-used debt is also an interesting one to think about.

  • Developers who spend time fixing “Phantom Debt” can be a big problem. They not only waste their own time fixing problems that don’t need to be fixed, but they waste the time of other developers that need to fix bugs introduced by superfluous changes.

  • Technical Debt is attributed to Ward Cunningham and it is important to note that Ward was talking strictly about how our understanding of the domain evolves, thereby creating the need to refactor.