1. 11

  2. 1

    I really like this idea, especially the retrospect on where time is lost as you go about your week delivering things. Data collection is useful for pushing back against the internal tribe that is incentivised for delivering features: having information to back up your claims is paramount. It can even help you identify what habits you have yourself that are slowing you down unnecessarily. I’ve seen some suggestions in the past week to record yourself programming, and annotate it afterwards at 10x speed.

    One thing that this article missies is that it’s important to note that technical debt can take different forms. Technical debt may manifest as a technical risk which threatens to bring your system down. These tasks have to be tackled eventually, but they don’t decrease your time spent delivering features. As a result, they may not get as much as attention.

    Another thing that this article has prompted me to think of is what way this could be set up in a remote engineering team. My team doesn’t have a physical wall to put stickies on. It seems that visibility is key, so maybe I’d want to have a trello board that pinged a slack channel with aggregated statistics or reports.

    1. 1

      “Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no longer valid, or just plain wrong. They incur a cost on future development. The shortcuts taken today will later slow you down, until you “pay back” the debt by fixing the problems. And it’s not just code: artifacts like architecture, documentation, tests, and domain models, can all suffer from technical debt.

      Do people actually categorize technical debt this way? I’m stuck in a rut with my org because the technical debt definition is too broad. Since we measure and allocate a specific amount to technical debt, it’s important IMO.

      One that I heard that I prefer is “Did we knowingly create that technical debt?” If so it’s tech debt, otherwise it’s not. Any opinions?

      1. 1

        Good point. I have the same quibble with that definition (though I liked the article a lot).

        I don’t think it matters at all if we knowingly created the debt … it only matters that there is something that slows us down that we know we could improve.

        In other words, “debt” is too limiting. Technical “opportunities” also exist, and you’d want to manage them pretty much in the same way – by identifying them, trying to size the potential benefit, and then pitching them to whoever controls the roadmap.

        1. 1

          I’ve rarely run into technical debt that was created knowingly. I don’t think most development is that self-aware, or able to predict the future. Often the decisions are perfectly reasonable at the time. This is where I think the “debt” word in “technical debt” is misleading: when you take on debt in the real world you know you’re doing it. I would best most technical debt in the software world was never taken on intentionally. And wasn’t even debt at the time - it only became debt maybe years later.

          My personal definition is any previous technical decisions - whether it’s code that was written or choices of technologies - that are now burdensome through producing more bugs, having extra complexity compared to alternatives, creating greater mental load or annoyance, or just plain slowing us down.

          Here are some examples of things I consider tech debt, at my current employer. Some or all of these decisions made sense at the time (all of them precede me, though I suspect if I would have made the same call on at least some of them)

          1. One of our teams chose Storm way back in the day. I expect that at the time it was a good decision, and it’s generally served us well, but Storm has been superseded, and is looking pretty long in the tooth, and now it’s holding us back and we want to get off it (or, so I’m told).

          2. The first developer they hired didn’t know what they were doing re: databases and now we’re stuck with Mongo. It’s a mess, but we’re essentially locked in at this point and I can’t see us ever getting off it

          3. A lot of our major application is written in Coffeescript. At the time this was probably a reasonable choice, but it’s now a dead language whose best features have been rolled into Javascript. We have tens of thousands of lines of coffee code, with no tests, that no-one wants to work on. New developers don’t want to learn Coffeescript (even though it’s fairly easy).

          4. We have an application built with NWjs. At the time this was chosen it was probably not at all obvious that Electron would become the clear winner, and that in 2020 would be leagues ahead in terms of features. NWjs putters on (barely) but we (and probably no-one else) would choose it over Electron today.

          1. 1

            That makes sense to me. Thanks for those examples. I guess my definition is a bit limited.

            I want to ask you another question though based on your definition - do you consider bugs technical debt?

            1. 2

              do you consider bugs technical debt?

              Not usually, though I might consider the root cause to be technical debt. For example, we might have a bug because we have a document in Mongo that’s missing a field that our application code is expecting to exist. The top-level cause is the missing field, but the root cause (at least, in my mind) is that Mongo doesn’t support schemas or constraints and if we were using a DB appropriate to the application we wouldn’t be able to have this kind of error at all.

              1. 2

                Got it. Thanks for the conversation!