1. 14
  1. 11

    “Every minute spent on not-quite-right code counts as interest on that debt”.

    I like the conceptualization of technical debt; it’s easy to explain, fits pretty tightly. But I’m pretty sure every project manager I’ve ever had doesn’t understand how debt works.

    The important part isn’t the principle, it’s the compounding interest. Every subsequent feature, or related commit with that original debt brings additional debt. Even after you’ve paid off the principle, all of that will still remain.

    1. 4

      In my experience, the answer is always “tomorrow”.

      1. 2

        Although I really agree with this post, sometimes the context is unfavorable. For instance in “startup’s” scenarii where time to market is sometimes the most important thing, time becomes a constraint and goes against “Doing things right”, unfortunately. (If anyone has experience dealing with this kind of scenarii, I’m all hears.)

        1. 4

          If time to market is the most important thing your business is undifferentiated and doomed anyway. Successful startups often do move fast, but it’s no so fundamentally essential as this

          1. 4

            After working in a startup which initially skimped on QA and then started taking it seriously (not playing at taking it seriously, but rather a new tech lead came in), I think it’s naive for startups generally not to worry about tech debt. The problem is, if you’re building anything even remotely complex you can get to crippling tech debt in weeks, long before you are anywhere close to an MVP.

          2. 1

            This all depends on the broader context in which code is getting written. There’s no discussion of the incentives which lead to debt and guard against fixing it. It would be nice if our industry were to do science on quality, rather than just opinion.