Why Are You Asking Me This Now?

Photo by Walter Olivares on Unsplash

Someone walks into your office. Or opens a Slack thread. Or books a meeting with a vague title.

And they ask: should we rewrite this?

Here's the question you have to ask before you answer that.

Why are you asking me this now?

Not "what's the technical debt?" Not "how long would it take?" Not "what does the team think?"

Why. Now.

Because the timing of the question tells you almost everything about the real problem. Someone asking after three consecutive missed sprints is telling you something different from someone asking after a competitor just shipped a better product. Same question. Completely different answer.

The golden pot at the end of the rainbow

Rewriting is romantic. I get it.

The clean slate. The chance to finally do it right. No more legacy code held together with duct tape and the prayers of engineers who left three years ago. Just clean, elegant architecture and the wisdom of everything you've learned since the last time.

It's a beautiful dream. And sometimes — sometimes — it's real.

But "let's start from scratch" is also one of the easiest ways to avoid doing the hard work of finding an actual solution. Because the hard work is figuring out whether your problem is really a technology problem at all. Does the rewrite solve something real? For whom? Does it solve it now, when your users actually need it? Or in eighteen months, when the competitive window may have already closed?

Can you buy a solution instead of building one? Use open source? Iterate on what you have while the team ships features that pay the bills?

These are uncomfortable questions because they lead somewhere slower and less satisfying than "let's rewrite." But they're the right questions.

If it ain't broken, don't fix it. But sometimes it's broken.

I don't have a default bias toward rewriting or iterating. Neither should you.

What I do have is a mental image I come back to: a train travelling at full speed toward a wall that's a hundred miles away. You can see it clearly. You have time. That's not an iteration problem — that's a course correction. The rewrite is the right call, and the earlier you make it, the cheaper it gets.

But if the wall is three miles away? You don't rip out the tracks. You brake.

The signal I look for before recommending a rewrite isn't technical. It's cumulative. It's when every attempt to fix something breaks something else. When the tech debt isn't just slowing the team down — it's demoralising them. When capable engineers start describing their own codebase like it's a crime scene. When every conversation about a new feature starts with the same sentence: "well, first we'd have to..."

If every road leads back to the same fork, and the sign at the fork keeps saying rewrite — maybe it's time to listen.

The one thing people don't say out loud

We are the people making these decisions. And motivation matters.

A team that no longer believes in their own solution will not iterate their way out of it. They'll patch. They'll complain. They'll leave. That's a cost too, even if it doesn't show up in a sprint estimate.

I've seen teams come alive after a rewrite decision — not because the new code was better on day one, but because someone finally acknowledged that the old thing wasn't working. That acknowledgement alone is worth something.

I'll also say the thing nobody with a VC badge wants to hear: with AI, rewriting is now significantly cheaper than it used to be. That changes the calculus. The expensive part was always the hours. When the hours compress, some decisions that used to be too costly to make become genuinely viable.

Though I'd gently note: anyone telling you AI does the whole rewrite for you is either lying or has invested in AI. The judgment calls — what to build, how to structure it, when it's actually done — those are still yours.

The honest version of my own track record

I've probably erred more on the iterate side than I should have. There were a few times I held on too long to things that were fundamentally broken, trying to fix what needed to be closed.

Closing a book is hard. Opening a new one is scary. But sometimes that's the job.