Here’s one of the better write-ups I’ve read on the concept of technical debt, from apenwarr:
I really like the “tech debt” metaphor. A lot of people don’t, but I think that’s because they either don’t extend the metaphor far enough, or because they don’t properly understand financial debt.
So let’s talk about debt!
Tech Debt Metaphor Maximalism on Apenwarr
I learned things about debt and finance reading this, and it certainly helps bring much needed nuance to discussions about technical debt.
The discussion on Hacker News also had this comment that I loved, and I think I’ll use as alternative framing at work when discussing the need to keep code-bases healthy:
I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.
He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.
So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.
sonofhans on hacker news