Eight Agile Wastes of Hanukah: #4 Technical Debt

Following the nightly lighting of increasing numbers of Hanukah candles, it is customary to sing traditional songs. 

Ma'oz Tzur (Rock of Ages) is a popular choice. Here's a nice choral version.

And then there's Adam Sandler's Hanukah song.

Agile Waste #4: Technical Debt

Technical Debt is a metaphor concocted by programmer Ward Cunningham, who also famously invented the wiki. It's a term to help non-technical people and (to a degree) technical people appreciate the insidious consequences of compromising internal technical quality.

What is it? Sometimes (for good reasons or not) developers rush out a feature and do a quick and dirty job. The trade-off here is that the feature is available more quickly to users, but the  the code-base becomes messier and more difficult to maintain, and future feature development will be slower and less efficient.

Here's the metaphor: It's like when you take out a loan. The loan allows you to buy nice things that you couldn't otherwise afford [release new features early], but then you have to pay interest on your loan [clean up the mess you created] as well as pay back the principle [re-write the ill-advised bits of your hackery]. The longer you take paying back the loan the greater the total interest payments [lost productivity].

Technical debt isn't all bad. It makes sense to slam out a fast prototype when you're trying to determine whether a new product or feature is high or low value (see Agile waste #1: Low value features). If it turns out to be low value you can just throw away the code (and not pay back the debt). But, if it's high value the right thing to do is a thorough clean-up or possibly re-write straight away. 

The insidious bit? Once a feature works the internal hackery to get it up and running is easily forgotten; the effects of the debt will bite later and there's demand for other new, shiny stuff right now. In non-engineering led companies especially this effect can be spectacularly magnified over time.

What to do instead

Always reserve some capacity for paying back technical debt. The real trap is to just keep on incurring increasing amounts of debt and lose the attention to technical excellence that goes with keeping your code-base clean and modular.

A classic way of incurring debt is to skip writing automated tests (see Agile Waste #3: Defects). Writing your tests first —BDD and/or TDD style — helps with both the design quality and psychological discipline needed to avoid the technical debt trap.

In an organisational setting a critical role for technically literate leaders is to educate their non-technical leaders about the very real consequences of unmanaged technical debt and together avoid falling into a debt trap. Incur enough technical debt and you'll kill productivity, and eventually your competitiveness.

Finally, here's some excellent advice from Andrea Goulet on what to do if you do find yourself mired in technical debt: Forget Technical Debt — here's how to build Technical Wealth.