|
> The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. The reality of rewrites is that they're often blamed for all of that, while the issue is not the rewrite. The issue is that companies that write bad software will, if given an occasion, write bad software again. The issue with rewrites is actually that they're not large enough in scope. When you rewrite software, you should probably also rewrite contributors' interactions, the way the company handles power dynamics and, occasionally, the way accounting works at that company. Short of systemic changes, rewrites are likely to fail. But again, the company is also likely to fail other initiatives aswell. Rewrites that fail in an isolated way are few and far between. > Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention. OR it might be a dumpster fire that drives your engineers away, one that is fueled by unreasonable deadlines and expectations. Also good luck refactoring your codebase at snail's pace with noncomitting approval, on your own unpaid overtime. |