Every senior developer will tell you: Clean as you go. Touch a class, leave it better than you found it. It's practically a professional virtue. I strongly disagree!
Here's the part nobody says out loud: clean as you go isn't free, and it isn't strategic. It feels free because you're "already in there anyway." But digging into dependencies, refactoring safely, testing that nothing breaks, that all takes real time. Time that was never budgeted. Time that gets pulled from the estimate the Product Owner agreed to, without them ever agreeing to it.
And it isn't strategic because you clean what you happen to be touching, not what actually matters. You might spend an hour tidying an Apex Class that gets deprecated next month, while an overexposed Permission Set sits untouched three Objects over, because nobody happened to open it this sprint. Proximity is not priority.
The real issue is who's making the call. Clean as you go quietly moves prioritization away from the Product Owner and hands it to whoever happens to be in the Org that week.
The fix isn't to stop cleaning. It's to stop hiding it. Go to your Product Owners and say it plainly: we want ten percent more time per User Story for cleanup, here's why, here's what it protects. Let them decide with full information. Or better, give cleanup its own dedicated track, prioritized like everything else, instead of smuggling it in one class at a time.
Dedicated, deliberate cleanup beats "as you go." Every time
Book a free 60-minute Salesforce Technical Debt Audit: a score for Usability and Build Quality, and your top cleanup priorities.