Straylight Run

Ward Cunningham reflects on the history, motivation and common misunderstanding of the “debt metaphor” as motivation for refactoring.

I first heard the term technical debt when I was learning about Scrum.  It immediately struck a chord because it made so much sense!  Technical debt described those times I coded the quick and dirty way (incurring debt) and not the way I wanted.  Technical debt described all those times I wanted to refactor an ugly system (and pay down debt), but couldn’t due to deadlines and the fact that it’s so hard to demonstrate the value of better code when the business output is the same.

As Steve McConnell says about this attitude towards debt:

I’ve found that business staff generally seems to have a higher tolerance for technical debt than technical staff does. Business executives tend to want to understand the tradeoffs involved, whereas some technical staff seem to believe that the only correct amount of technical debt is zero.

Like financial debt, a little technical debt is okay.  After all, if the viability of the business depends on releasing a product, saving the business is more important than feeling good about your architecture.  But you have to service the debt at some point, and fight the common business notion: if the software works, then it’s good enough.

Because the tax man will come to collect.  And you will know when he does when you attempt to change someone else’s (or perhaps your own) old code and you see that you have to change 40 files to make a tiny feature because the whole system is a big ball of mud and you grumble something about doing it right the first time.

I thought about all this when I read Jay Pipes’ advice to MySQL.  Years between releases… Bug fixes that cause bugs…  It sounds like the tax man has come to collect at MySQL.  He argues for taking a year break to pay off the technical debt in MySQL.  Ouch.  That’s quite a bill.

Now, I consider Jay to be one of the smartest persons I’ve ever met, but I have to disagree on this one.  The thought of stopping new work to radically alter a huge working system and ultimately release it a year later in a Big Bang terrifies me.  If you were really, really, good, you could be successful at this and maintain quality and measure output and do tons of integration testing, regression testing, etc.  But one thing that I believe is oft overlooked is that developers like to release code.  And the more time that goes by without any released code, the more it feels like days are just wasting away.  That’s been my experience anyway.  But I digress.

Much like our credit markets these days, after accumulating so much debt, you find that you cannot move.  You feel stuck and trapped and spend all your energy trying to stop moving backwards, instead of moving forwards.