found drama

I particularly liked the post “Towards an understanding of technical debt”, and mostly because the author is skeptical of the common thinking and conventional wisdom around the subject. The key takeaway is that when people talk about “technical debt”, they tend to conflate five different kinds of problems:

1. Maintenance work
2. Features of the codebase that resist change
3. Operability choices that resist change
4. Code choices that “suck the will to live”
5. Dependencies that resist upgrading

He invokes Norvig’s “all code is liability” here — which is pithy and memorable, but overstates the case — but ultimately his point is: technical debt is shorthand for one of these five scenarios where our complaints are ultimately rooted in the fact that we’re taking on the perceived burden of unpleasant work — usually due to some kind of implicit resistance or inertia of the codebase. (And this dovetails nicely with Simler’s “A Codebase is an Organism” post that made the rounds recently.)

From a practical perspective, the lesson seems to be: when you start invoking the phrase “technical debt”, try to consider which of the 5 categories the scenario fits into. What kind of resistance or inertia are you facing? And how can you move things forward without resorting to “technical bankruptcy” or “papering over” the problem with an Nth-level of indirection?

About !undefined