Technical Debt is usually referred to as something Bad. One of my other articles The Solution to Technical Debt certainly implies that, and most other articles and books on the topic are all about how to get rid of technical debt.
But is debt always bad? When can debt be good? How can we use technical debt as tool, and distinguish between Good and Bad debt?
(related article: Good and Bad Technical Debt – and how TDD helps)
(Translations: Russian)
Are you in a software development team, trying to be agile? Next time the team gets together, ask:
How do we feel about the quality of our code?
Everyone rates it on a scale of 1-5, where 5 means “It’s great, I’m proud of it!” and 1 means “Total crap”. Compare. If you see mostly 4s and 5s, and nothing under 3, then never mind the rest of this article.
If you see great variation, like some 5s and some 1s, then you need to explore this. Are the different ratings for different parts of the code? If so, why is the quality so different? Are the different ratings for the same code? If so, what do the different individuals actually mean by quality?
Most likely, however, you will see a bunch of 2s or worse, and very few 4s and 5s. The term for this is Technical Debt, although for the purpose of this article I’ll simply call it Crappy Code.
Congratulations, you have just revealed a serious problem! You have even quantified it. And it took you only a minute. Anyone can do this, you don’t have to be Agile Coach or Scrum Master. Go ahead, make it crystal clear – graph the results on a whiteboard, put it up on the wall. Visualizing a problem is a big step towards solving it!
Don’t worry, you aren’t alone, this is a very common problem. <rant>However, it’s also a very stupid, unnecessary problem so I’m baffled by why it is so common.</rant>
Now you need to ask yourselves some tough questions.
Here are the slides from my session “Technical Debt – how not to ignore it” at Agile 2008 in Toronto. Translations: Portuguese (thanks Demetrius Nunes)
Continue reading