I previously wrote a post that discussed what technical debt is, how it comes to be, and some ideas about how to handle it. I recently came across a blog article written by Don Reinertsen. In this article, he looks at the Technical Debt metaphor and lays out some math to form an economic model about when and why to pay it. In my previous post I didn’t really address the why and when of spending resources to improve internal quality at the cost of additional functionality.

Well, it is an economic decision. Yet, if you totally avoid paying technical debt, software systems will;

1. take more and more effort (cost, delay) to support and extend
2. eventually lose all ability to extend without an extensive re-write

On the other hand, there is a legacy in software engineering of pursuing the perfect design and never delivering functionality any customer wants.

So this is where I think Don’s post helps. There is no magic answer or formula that will remove the need for people to think and use judgment. The scrum team should be identifying what’s needed to reduce technical debt. The team can help the situation by splitting up the chucks of work as small as possible. How much to pay or when should be the team with the product owner making an economic decision. Sometimes delay make sense and sometimes it doesn’t.

Here is a link to Don’s post; reinertsenassociates tech debt metaphor math

Thoughts?