Blog of Rob Galanakis (@robgalanakis)

Technical debt metaphors get it so wrong

In my previous post about technical debt, I explained how modern definitions of technical debt are harmful. Now I turn my attention to equally harmful metaphors.

Viktoras Makauskas made the following metaphor in a comment on my last post. This is a pretty perfect stand-in for metaphors I’ve read in other articles that harmfully define technical debt.

Imagine your car gets a strange rattle. You go to your mechanic and he says, “it’s your exhaust pipe holder, you need to replace it, but it’s gonna take a while to order a part and ship it, so just park your car here and come back in a week”. You say “no, I have this weekend trip planned, is there something we can do now?”. They say “yeah, we’ll put a strap on it meanwhile, just drive a little more careful and it should hold, but make sure to come back and do a proper fix”. Mechanic charges you now, and then a bit later.

This seems sensible on first read. But upon closer inspection, it’s quite clear the roles here are totally wrong*:

  • The mechanic is the programmer (the role of the “expert”). Well, a mechanic may or may not see your car ever again. They do not have a vested interest in your choice. A mechanic’s relationship to a car is totally different from a programmer’s relationship to code.
  • “You” are the “business” (the role of the “stakeholder”). The metaphor assumes that if you are irresponsible, it only impacts you (it’s your car, your money, your time). This is a problem. A programmer is impacted by business decisions in a way a mechanic is not impacted by whether you fix your car now or later.

This isn’t a simple language problem. It is a fundamental misunderstanding of roles that is naive to the way software development works. Programmers will be the primary sufferers of technical debt. Eventually the business will suffer with a slower pace of innovation and development and higher turnover. But well before that, programmers will be fixing (and refixing) obscure bugs, will bristle under management that tells them to go faster, will be working extra hours to try to improve things, and will eventually burn out. The business will only suffer once real damage has been done to a programming team, and many have given up.

This is why control of technical debt must be in the hands of programmers. Definitions or metaphors that urge otherwise are actively harmful.

Let me close by pointing out I’m just repeating what Ward Cunningham has already written about the original technical debt metaphor. The article ends with:

A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.
I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

Thanks Ward.

* There are also a couple other problems with this metaphor. First, if “you” and the mechanic are the same person, and responsible for both business and implementation? In that case, there’s no need for a metaphor at all. Second, what happens if the exhaust fails? Do you become stranded? Does the car catch fire? What’s presented here is a false choice between a “correct” solution (replacement) or a “sloppy” solution (strapping it on). Why not rent a car? If there’s no responsible-but-relatively-cheap decision (there almost always is!), it’s still never acceptable to make an irresponsible decision.

4 thoughts on “Technical debt metaphors get it so wrong

  1. Viktoras Makauskas says:

    I guess you can twist the metaphor multiple ways, depending on which fighting side you are:)

    Yeah, the tech debt primarily hurts developers. Yeah, it is unpleasant when client insists to “strap the pipe”, then comes back saying that the whole car caught on fire. But what about situations where client only had time/budget for the strap, and are happy because we found a quick solution that works for their needs?

    Anyway, a real example. A defect comes in saying that a “submit payment” button of our older web apps does not work on a specific android version. We investigate and discover that the issue is in a third party JS library. The problem is fixed in it’s later release, however, a few dependent libraries will also have to be upgraded in our app, probably not without changes to our own code. This means more dev and testing effort. As the client wanted a solution NOW, as it’s impacting his business in a pretty straightforward way, a workaround was done to actually track down the relevant change in the 3rd party library (boiled down to few JS lines), patch the version we’re using, and deploy. It was ugly but it worked. Yeah it was not pretty, but to team’s decision, safest approach given the situation.

    1. So I just discovered that, on OSX:
      – alt+space to open Spotlight accidentally
      – escape to close it
      – Your WP comment closes (in admin view at least) and it’s all erased…

      I will respond another time, but the gist of it is, your solution there is minor and common and likely what you would have done even without client pressure (would you really want to upgrade an old app)? Everyone does this sort of thing, especially in JS.

  2. Jse M says:

    “But what about situations where client only had time/budget for the strap, and are happy because we found a quick solution that works for their needs?”

    Your scenario assumes that the customer accepted the responsibility and will not come back to the mechanic if there is fault.

    This does not happen for developers, it’s always their fault, it always comes back, they always have to fix it. Under the later assumption (the one I just made), the mechanic should apply a solution he can live with, because he knows the customer will come back with the same issue or a new issue caused by his work.

  3. […] 50 minute webinar explains what technical debt is and how to manage […]

Leave a Reply