At what point does a messy codebase force you to stop and rewrite?
by•
We put off refactoring for way too long last year because we were so focused on launching new features every single week.
Eventually the codebase got so fragile that fixing one simple bug broke three other things in the app. Taking a few uninterrupted days to clean the foundation completely changed our speed going forward.
It really is the best investment you can make even though it hurts to look at an empty changelog at the end of the week. How do you decide when the tech debt is finally too heavy to ignore?
7 views
Replies
My line is this: refactor when the mess slows you down, rewrite only when the foundation itself is wrong. I did one full rewrite. The old app let the client write its own purchase counters, re-fetched every song on a timer, and stood on an API that could vanish. None of that could be cleaned up in place, because each of those was a decision, not a mess. The new app was built on the layered structure of another project of mine, so I started from a worked example instead of a blank page. Messy code you can fix a file at a time. Wrong decisions spread into every file, and that is when cleaning stops paying.