The Biggest Mistake a Developer Can Make

Why rewriting software from scratch is usually a terrible idea

Posted by Hüseyin Sekmenoğlu on December 20, 2019 Architecture & Patterns

Let me give you the answer right away:
The biggest mistake is rewriting an entire codebase from scratch.

There are many painful examples in software history. One of the most famous is Netscape. If this were Wikipedia, I’d simply link you here:
https://en.wikipedia.org/wiki/Netscape

This was the company that developed JavaScript. At one point, they had almost no competition. Internet Explorer barely existed. They even sold to AOL for 10 billion dollars. But after version 4, the team decided to rewrite their browser from the ground up. That rewrite took over three years, and by the time they were done, they were gone from the market. Eventually, they open-sourced the code and that’s how Mozilla was born.

This article isn’t really about Netscape though. It’s about something I experienced in a company I worked at.


🏗️ The Rewrite That Shouldn’t Have Happened

We had a large application. The current version had taken nearly two years to build. Several customers were using it every day without issues. Then one day, a new developer joined the team.

In their first week, they told the boss the code was too messy and that they could rebuild the whole thing in a few weeks. The boss agreed without talking to anyone else.

At first we were happy. We thought this new hire would help the team. Instead, they kept to themselves, avoided real work, and constantly needed help. That’s when it hit us: they weren’t helping—they were replacing.


👷‍♂️ Developers Are Architects and Builders

Most developers have a strong urge to start from scratch. Fixing or improving existing code just isn’t exciting. The most common reason? They see old code as a dumpster fire. But that’s often just because reading code is harder than writing it.

This is why many developers prefer building their own utility functions, even if similar ones already exist. Ask any developer today and they’ll likely say they’d prefer rewriting a legacy system. Their reasoning usually sounds like this:

  • This function is similar to what I need, but I don’t get what it does

  • This method is two pages long and impossible to follow

  • It calls way too many APIs and I don’t understand why

But here’s the thing: that old code works. It has been tested. It has survived real usage. Every strange line might be protecting against an edge case that once caused a bug.

Even if you rewrite it all, how can you be sure your version will be better? Two years from now, someone else will say the same thing about your code.


🔧 So What Should You Do Instead?

Learn how to refactor.
Learn how to improve what exists instead of throwing it away.

Here is a great place to start:
👉 How to Refactor Legacy Code – YouTube