I do a lot of technical due diligence for companies in a bunch of different contexts (private equity pre-acquisition, post acquisition, management change over, etc). I have found that tech debt is highly correlated to the business goals and tech organization structure, and has to be evaluated in those contexts.

Startups you want to see with fairly high tech debt. Tech debt there is a very often a sign of shipped code that is meeting some customer need. You do need to watch out for insane tech debt that may be hard to undo later on (running everything in an ancient proprietary language for example).

Startups with low tech debt often are devs navel gazing without a lot of revenue coming in. This is surprisingly true almost all the time.

Very large companies will tend to have a mashup of all kinds of technology that is never fully untangled. A very large Corp with little tech debt is exceptionally rare. If it ain’t broke don’t fix it is the rule.

Mid sized corps and late stage startups seem to be the sweet spot. Fairly low tech debt systems that is providing high value is still possible. This is where you have enough maturity to know what “good” looks like, and enough developers, momentum and budget to implement the vision.

One small anecdote of a project at work. The oldest current project. All our projects are fairly simple and similar. They all use libraries and templates. This one is the last of the early projects before those templates and libraries. It's the easiest to manage. Things rarely go wrong. No forced upgrades because of a library vulnerability or template update. Bugs have been always been straightforward to find and fix because everything is procedural and clear. No abstraction 7 layers deep. Just clean, simple code.

Code doesn’t have to be perfectly maintainable and „elegant“. It just has to be useful i.e. good enough. If it solves your user‘s problem, that’s good enough. If your development speed can keep up as you add new requirements, that’s good enough.

Doesn’t mean you should ship untested code because that would decrease both the value to the user and your development speed. There are projects out there that go into the other extreme, entering the realm of premature abstraction and accidental complexity. In my experience that’s even worse because in that case it’s hard to convince stakeholders that there even is a problem.

It‘s a tough pill to swallow for devs with perfectionist inclinations like me, but at the end what matters is providing value to the user. In fact, I think technical debt will always be present as long as requirements change, and as the saying goes, change is the only constant in software engineering. It‘s not something to be completely avoided as that’s impossible. It just needs to be managed in a pragmatic way to keep up velocity.

Every engineering team I've worked with virtually every engineer complains about technical debt - regardless of how much time is allocated to manage it. I'm not suggesting it isn't important to take care of it, just that sometimes it comes across as the boy who cried wolf.

I have micro-services that haven't been touched in years because they do one thing, and the requirements of that one thing never change.

It is possible but only in your own projects as tech debt is the result of:

Programmers who aren't you, and those damn MBAs ruining your flowstate