Just because it's old, doesn't make it tech debt.

I spent a very long time early in my career incorrectly thinking that obsolete abstractions were tech debt.

Finding time to reduce tech debt is an important part of balancing development time. Making up for intentional previous trade offs in quality for time is tech debt. A mental model or abstraction can become unsuitable for users as the variety of use cases grows.

Replacing these abstractions should be a part of product process, not tech maintenance. Replacing abstractions without concrete use cases will lead likely to premature optimization and new abstractions which are unlikely to be correct.

Backstory

I'm now leading product at a logistics technology startup with a code base roughly four years old. Recently we needed to scope an upgrade to how we store prices for point to point transport of goods. The setup we designed would map prices against two locations. These locations could be concrete places, like a warehouse, or broad locations like a suburb.

In designing this setup, we found that a number of other places in the code base had similar concepts. We made the call that this unified location model brought a lot of quality of life additions and would work to migrate the code base to use this new model where we could. After input from the development team, it turned out this would be a big job. One we initially painted as cleaning up years of tech debt.

It's easy to come into an existing project, or look back on a long running one and assume everything from the past is out of date. Having done the work it is easy to look back and pick out issues. We need to remember that what we needed yesterday might have been different from what we need today.

Along those same lines, building next year's solution today isn't the right move most of the time. We assume we know better looking backwards but I'd bet a year from now, whatever we build today will have it's flaws too. Building products, especially software, is rarely a bounded process. We grow, requirements change and the world we're building in continues to shift.

Treating everything we've done in the past as tech debt or a mistake only serves to make us miserable. Yes, tech debt is real but it should be reserved for real instances of trading off speed for completeness, not a change in complexity or requirements.