found drama

get oblique

Tag Archives: technical debt

“technical debt” as shorthand for five different scenarios

by !undefined

Towards an understanding of technical debt:

Particularly liked this blog post on 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?

re: Peter Bell on “Innovation Debt”

by !undefined

“Just as technical debt can kill a code base by turning a green field project into a big ball of mud, innovation debt can kill an engineering team – moving them from a cutting edge crew to a group that’s barely competent to maintain a legacy app.”

–

Peter Bell, Innovation debt

There’s the argument that “innovation debt” is just another form of technical debt — that the latter isn’t just the tests you didn’t right, but the opportunity costs of not exploring alternatives.

What I like about this post is that, assuming you take a measured approach here, you can use a combination of these techniques to keep engineers interested and happy. You can give people the room to explore some new technologies and maybe, if those technologies actually are good choices, then by all means bring them into the stack.

That being said, it’s almost too easy to read Bell’s post and use it as a justification for your own Magpie Syndrome. A “culture of learning” is great — but recognize that your exploration can also lead to another, equally valuable bit of knowledge — the knowledge that after exploring some new piece of technology, that it’s actually not a good idea to move forward with it. Trying new things is fine — and you should explore alternatives — but sometimes your innovation is “add Java 8 streams” and not “rewrite everything in Scala”.

I also feel like it’s worth calling out (for the tech leads in the audience) that not everyone wants to do shiny new stuff all the time. (See also: Matt Asay’s thing re: “developers calling it quits on polyglot programming”.) “Innovation debt” as Bell describes it sounds like it goes a couple ways: the “explore innovative shiny new things” way, and the “double-down on what you have and make sure your engineers know their shit” way. Ignore both at your peril.