I think about rewriting code a lot. If you’ve been at it for enough years, you’ll inevitably find yourself in many conversations about whether or not a team should be rewriting a codebase when faced with a project that is opaque, frustratingly slow and nonsensical. It can very quickly feel like a rewrite is the only option.
Developers will often advocate for that solution, and I understand why. It can be liberating. It’s like clearing away an overgrown thicket to reveal a perfectly clear path ahead. If only the code was cleaner and more maintainable, the argument goes, we could deliver even more new features in half the time. We just need to refactor it first.
But that is rooted in a flawed premise. Like anything, software tends to deteriorate over time and usually, it doesn’t necessitate drastic measures like a complete rewrite. Instead, what it often requires is simple, boring, regular old maintenance. I’d be willing to be that if you are considering a rewrite, it’s probably the wrong idea.
A lot of the value that an agency like mine brings to a project is that perspective. When a client comes to us with an untenable codebase, we know how to maneuver through them, identify the most critical issues, and triage different parts for a more selective, focused refactoring that emphasizes incremental change. In other words, it’s our job to understand what we’re working with and identify the places where we can have the biggest impact.
It’s a mark of a seasoned programmer to have the ability to do that and the willpower to resist the temptation of a rewrite.There’s a reason that Joel Splosky named it the single biggest strategic mistake you can make. The value that you add to a codebase is usually going to do little more than match the effort that’s already gone in. There are definitely cases when a rewrite is necessary, but they are very rare.
And so we need to face the fact that the trajectory of the React project is at odds with what most experienced programmers can agree is a commonly accepted principle. Because React changes a lot. It’s very nature necessitates either pinning yourself to some obscure version, or being in a constant state of either preparing a code rewrite or just having completed one.
It’s I think the most profound insight in Simon MacDonald’s removing React is just weakness leaving your codebase. React is not static but it doesn’t organically evolve. It unveils entirely new best practices and internal APIs every few years. And every time it does, we are forced to rewrite. And again, rewriting is typically a bad idea.
By choosing React, we’ve signed up for a lot of unplanned work. Think of the value we could have produced for our users and company if we weren’t subject to the whims of whatever the cool kids were doing over in React.
Stop signing up for breaking changes!
Our code is filled with breaking changes. We don’t need our frameworks to add more.
Bookmarks & Notes
MacDonald also references the rule of least power, which I had never heard of.
When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.
W3C
There is no moral imperative to be miserable, and nihilistic resignation is the most conservative affect of all.
To be truly radical, James Greig suggests, you can try to take control of your own state of mind.
