Technical Debt

Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team’s work become a “debt” that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are…

Debt is sometimes useful. Financial debt can be used for risk reduction, investment, and emergencies. But it can also cause problems. Too much debt becomes hard to manage. If debt maintenance costs more than revenue (minus other expenses), then you’re going down!

Technical debt is a little different than financial debt.

Suppose I went into a boardroom full of high-power executives for some large company. (Never mind how I got there.) And I pitched this fabulous idea: I’ll give them a bunch of money for them to use for operations, expansion, whatever. All they have to agree to is that I choose the interest rate when I ask for repayment… trust me!

I would be thrown out of that room so fast!

That is what we do when we encourage teams to take on technical debt.

There is no way to know the interest rate on a defect. Part of the cost of a defect is obvious: how much time and materials will it take to repair the immediate problem. (Although even that is often hard to measure.) But there are also lots of non-obvious and probably non-measurable costs. How much effort will it take to get to the root cause of the defect so that it doesn’t occur a second time? How much will it affect our “goodwill” and thus reduce further and repeat sales? How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs?

In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.

Read more about this:

Quality is Not Negotiable

Voluntary Technical Debt – James Shore talks about a situation where a conscious decision to take on technical debt led to positive results.

Technical Debt: The Threshold of Acceptable Pain – Steve Bate talks about skill and sensitivity to technical debt. Here’s a great quote from this article:

What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code…. The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. …they sometimes experience pleasure at being the “hero” who saved the company from the bugs they created.

An Incremental Technique to Pay Off Testing Technical Debt – Johanna Rothman talks about technical debt and describes a simple risk-oriented approach to reducing it.

If you find this useful, please consider contributing with our “Value for Value” model.