frontend
When You Should Actually Rewrite Everything
Thoughts from the intersection of code, craft, people, and progress.
Most rewrites are vanity. Here’s when they’re not.
Rewrites are appealing because the new system has not had time to disappoint anyone yet. Occasionally they are the right choice, but only when the current constraints are understood and the team has a plan beyond recreating the same problems in newer syntax.
The useful question behind “When You Should Actually Rewrite Everything” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.
There is a practical tension underneath this topic: we want enough structure to move confidently, but not so much that the structure becomes the work.
The most useful lessons often arrive through ordinary work. A choice feels awkward, a conversation goes better than expected, or a supposedly small task reveals something important about the system around it.
There will always be exceptions. The trick is to make them deliberate exceptions rather than habits nobody remembers choosing.