... if it aligns with business strategy.

As a junior developer, I worked at a startup on web apps with the worst code you've ever seen:

• Files with over 5000 lines of code
• Hard-coded values repeated all over the place
• Minimal use of functions
• Interpolated HTML.

🤮

Of course I tried to fix what I could but in these startups everything was high pressure and only new features mattered.

The apps were painful to maintain and changes took 5-10x longer than they should have. Yet some of these served hundreds of thousands of customers per day and made tens of millions in monthly revenue.

Within a couple of years this startup was acquired and this garbage code was someone else's problem.

There is an ongoing meme that technical debt is just bad and must be eradicated. This idea is understandably spread by developers because they're the ones who experience the pain.

While the engineer in me feels the same, if I look at things from a business owner's point of view, I'd say technical debt has its place.

But you need to understand the extra risk you're taking on, the good staff you may lose, and the increased cost to maintain your software.

Cost in man hours but also because accepting tech debt isn't a binary decision. Some changes are forced and you're going to need to know which ones are critical. To walk this line you need experienced engineers to advise you.

If you're OK with all that, maybe it makes sense.

And you know what's just as bad as technical debt? Over-engineering.