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.