Rewriting a system is one of the highest-risk calls a team can make. Here's how to tell whether it's actually warranted, or whether the real fix is smaller than it feels.
"We should just rewrite it" is one of the most expensive sentences in software. Sometimes it's correct. Often, it's a reaction to pain that a smaller, less risky change could actually solve. Here's how we think about telling the two apart.
The real question isn't "is this codebase unpleasant." It's "does this codebase's architecture prevent us from doing what the business needs next, in a way that a targeted change can't fix." That reframe alone rules out a surprising number of proposed rewrites.
Do it in a way that lets the business keep running: strangler-fig migrations that replace the system piece by piece, not a big-bang cutover after a year of silent development. The riskiest rewrites are the ones where nothing ships until everything is done.
Supereva Team
Engineering at Supereva Technology
Keep reading
Tell us about your project, and we'll show you how we'd approach it.