I've been thinking about this topic for a long time. When I wrote about rewrite projects back in 2014, I was looking at it through a Scrum lens - Product Owners checking out, teams skipping estimation, backlogs getting ignored.

But with the (eyeroll) wisdom of years, I've realized it's not really a Scrum issue. It's not a process issue at all. The rewrite project is just a hidden black hole loser of a project type, and it's strangely deceptive.

It's a hubris factory.

The Setup

You know the scenario. The company has an existing application that's been around for a while. It works, but it's showing its age. The codebase is a mess, the technology is outdated, maintenance is painful. So leadership decides: let's rewrite it.

On paper, this should be one of the easier projects an organization can take on. Think about it - you have deep knowledge of the business problem, you have proof that the problem is solvable (the existing app), and you usually have a team that either built or maintains the current version. There's enormous institutional knowledge. These aren't incompetent organizations. They built this thing and kept it running for years.

So why do rewrite projects so often turn into rocket-propelled, supersonic, train wrecks?

The False Confidence Trap

All that knowledge creates a false sense of security. The team feels like they understand what they're building, and therefore it should be easy. And then they skip the discipline (and healthy skepticism) that they'd normally apply to a new project.

If this same team were building something completely new, they'd be rigorous. They'd create a prioritized list of features. They'd work with stakeholders to figure out what's most valuable. They'd break the work into manageable chunks and deliver finished functionality incrementally. They'd estimate carefully and track progress. They'd dump features that don't deliver solid business value or deliver questionable business value. It would be obvious to everyone that you can't do everything at once, so you work on small pieces in priority order.

But on a rewrite? You'll hear stakeholders say things like "we don't need to prioritize - just look at the existing application and build that." There's a temptation for decision-makers to mentally check out. The requirements are "obvious," right? (And we need it all, too.)

Meanwhile, on the development side, the team thinks they already understand the application. So they either don't estimate carefully, don't break the work down properly, or come up with wildly optimistic timelines. "We built this thing before, how hard can it be?"

Put these two dysfunctions together and things go bad fast.

It's Not a Rewrite - It's a New Application

The way to break the curse is to change how you think about the project.

Stop thinking of it as "rewriting" the old application. Think of it as building a similar but new application. That mental shift changes everything.

Remember: the original version is filled with hundreds of little dissatisfiers that you're supposedly fixing in the new version. Every time you hear "build this screen exactly like version 1, except change X, Y, and Z" or "make this subsystem work just like before, except with a better database" - that's not a simple rebuild. Those are NEW requirements. You don't understand it the way you understood the old version anymore.

The moment you start changing things - and you will start changing things, that's the whole point - you've introduced uncertainty. And uncertainty demands discipline.

"Ehhhh...Just Build It All": Excellence in Applied Defeatism

Let's be honest. It's just you and me here. Admit it: the old application has tons of features that you personally never use, and you have no clue whether anyone else uses them either.

Rather than going through the actual effort of enumerating and justifying all the features, you're just saying "build it all." It's easier. It avoids hard conversations.

Because who wants to go tell Gladys in Accounting that she can't have her "export to Lotus 1-2-3" feature anymore? Gladys is so nice and she feels so comfortable with her completely outdated, dead-as-a-doornail spreadsheet app. It's going to break her heart. (Oh, and by the way, Gladys is married to the CEO, so pretty much whatever Gladys says goes by default anyway so whatever.)

One of the ways rewrite projects get wrecked is by loading them down with every silly feature that someone asked for a decade ago - features you don't even know if anyone uses. You're not building a lean, modern application. You're recreating the bloat, plus adding new stuff on top.

A new application would never get away with this. You'd have to justify every feature. But a rewrite? "It's already in there...somebody's gunna want it" becomes the ultimate non-justification justification.

This is where discipline matters. If you can't point to who uses a feature and why it's valuable, maybe it shouldn't make the cut.

The Real Problem

The deeper issue is that rewrite projects are often a symptom of something else: accumulated technical debt that's finally hit a breaking point. Years of shortcuts and "good enough for now" decisions have piled up until the codebase is so painful that a clean start looks attractive.

But here's the thing - a rewrite doesn't solve the underlying problem. It just resets the clock. If the habits and pressures that created the mess in the first place don't change, you'll end up right back where you started in another five or ten years.

And rewrite projects carry enormous risk. They take longer than expected (always). They cost more than budgeted (always). And there's a real chance they fail entirely, leaving you worse off than when you started.

What To Do Instead

If you're staring down a rewrite project, keep these things in mind:

Consider whether you really need a rewrite at all. Seriously. Think long and hard about the decision to take this on. Sometimes incremental improvement is the smarter path, even if it's less satisfying than a clean start. On the other hand, sometimes you're just stuck - "the warehouse inventory management system - yah...the one that runs everything - that's written in Visual Basic 6."

Treat it like a new project. Maintain a prioritized feature list. Break work into small chunks. Estimate carefully. Deliver incrementally. Don't let familiarity breed sloppiness.

Challenge the "build everything" assumption. The old application has features nobody uses. It has complexity that exists for historical reasons that no longer apply. A rewrite is an opportunity to shed weight, not just recreate the bloat in newer technology.

Watch for the warning signs. If stakeholders are checked out, if estimates are vague or missing, if nobody's tracking progress against a plan - you're heading for trouble.

The organizations that succeed with rewrite projects are the ones that clearly acknowledge the risks and respect the uncertainty involved. They apply the same rigor they'd bring to any new development effort. They don't let their knowledge of the old system trick them into thinking they understand the new one.

The old app is merely a reference. It's there for inspiration. It's not a blueprint. Proceed with caution and treat the project accordingly.

-Ben