Comment by Madhav Jaishi on "Would you build a skyscraper without blueprints?"

Couldn't agree more. This is exactly what’s happening in the project I’m currently working on at my company, which is why I was really looking forward to the solution you were going to propose.

When you wrote, “Technical debt piles up past the point anyone can dig out from under it, and the only option left on the table is starting over. It's the most expensive outcome on this list, and it's the one bad design was quietly building toward the whole time,” and then followed it with “So what actually changes this?”, I thought you were going to get into some practical solutions.

But the main takeaway seemed to be: consider design from the start, spend an hour on it, and it’ll save you a day later.

I completely agree with that in principle, but unfortunately, that doesn’t really solve the problem once you’re already in the situation. What do you actually do when the technical debt has already piled up and you’re dealing with a system that’s difficult to change?

I was hoping for some practical strategies for getting out of that situation, not just how to avoid it in the first place.

Fair callout, and you're right that I ducked the harder question. Let me actually answer it.

If the debt's already there, the fix isn't "stop and rewrite" or "grind through it." It's containment first, then chip away.

Draw a boundary around the worst part. Don't try to fix the whole system. Find the one module or table causing 80% of the pain and wrap it: an interface, a facade, whatever stops it from leaking into new code.
Freeze the bleeding before you treat the wound. New features shouldn't add to the same mess. Even a rule as blunt as "nothing new touches this file without a ticket" buys you room.
Write the doc while you fix it, not before. You don't need full understanding to start. You need to write down what you learn as you go. That doc is what stops the next person from re-doing your archaeology.
Strangler pattern over rewrite. Route new functionality through a clean layer that gradually replaces the old one piece by piece. It's slower than a rewrite feels like it'll be, but it doesn't stop the business for six months.
Sell it in the language of risk, not cleanliness. "This table causes X% of our incidents" gets budget. "This code is ugly" doesn't.

Basically: you can't retroactively get the planning hour back, but you can still write the blueprint late, just alongside the excavation instead of before it. Appreciate you pushing on this, it's a fair gap in the post.

Search Hashnode