Hacker News Reader

Comment by MikeTaylor | Hacker News Reader

"We'll do a rewrite, simplify everything, get rid of all the edge-cases."

Guess what? It turns out that all those edge-cases were there for a reason. You needed them. And by the time you've added them back, or equivalents, two things have happened. First, you've burned an order of magnitude more time than you budgeted for the rewrite. And second, you have a codebase every bit as gnarly as the one you started with.

First rule of rewrites: don't do it. Second rule of rewrites (for experts only): don't do it yet.

View on HN

Sometimes the reason has not been relevant for ten years, though, like when a codebase is filled with horrible hacks to account for the fact that you only have 64MB of RAM, while running in a vm with 4GB.

That is right, but you should be able to point at (preferable several) such assumptions that went into the original system, and verify that they are no longer necessary.

Maybe you used to have much less RAM in the past, but also much less data, or not as many users etc.

I worked on a java swing app that was deployed to a phone center as a Citrix app. Each instance was allowed only 64mb. Use if Citrix sidestepped all java version and deployment issues. Anecdote why memory limits can be relaxant today.

It is often junior ppl who request rewrites.

Junior as in * have been exposed to few real-world development projects, or, * have little understanding for the interplay between development and business. (The junior developer may however be very good at programming in languages X, Y and Z.)

Many developers will be junior under this definition for all of their career.

The exception I have seen from this is consultant sales ppl, who want to use the hype of the new often untested (or for the task non-optimal) technology or paradigm X.

When the original system was written by developers who were not junior, as is often the case with large successes systems that have survived, the result from letting junior developers rewrite the system, will be predictable.

Tip: Be cautious when listen to developers that talk about “technical debt” and similar. Make sure they are not junior developers under the definition above or are just not that good at reading code and understanding real world systems. Similarly, when listening to a sales pitch by a consultancy firm, make sure they have your interest in mind.

It depends.

One system I worked on was an information system in VB6 which was being used as a base platform to build domain-specific ERP implementations. Deployment in their environment to anything non-browser-based was a nightmare. There was overlap between domains although there was shared data (customer and supplier information, product database, that kind of thing). The obvious thing to do here was to let each domain (i.e. team) build their own solutions in the most effective platform for their domain whilst integrating via defined interfaces. That's not what happened; when I left few teams had anything working and those who did spent the majority of their time on deployment issues.

Another system I worked on was initially built by a very junior team under tight time and budget pressure under leader who believed in never saying "no" to the customer. They created a horrible mess (most of the code was in a couple of files). The system was deployed by two/three customers. Testing was done during deployment; the first version worked well enough to go into production. A year later everything had ground to a halt; there was no formalised testing and the developers couldn't fix one bug without introducing several more. One very smart developer started to "rewrite from the inside" by implementing new features using clean and modern techniques. At that point I took over the team. We doubled down on this "rewrite" whilst adding manual tests (and later automated tests) to cover the most important flows. We only rewrote features when they needed to change and in some cases removed functionality when particularly hairy features no longer worked.

Otherwise I advise against rewrites; if the system was reasonably built and the platform viable then rewriting is just a waste of money.

The edge cases aren’t removed, they are considered in the architecture of the rewrite while they were square pegs in round holes in the old system.

So rewriting and knowing the full scope is a luxury that allows a much better design.

The problem is that in the new system there will be new cases that don’t fit the new design.

Rewriting shouldn’t be a decision taken lightly but it also shouldn’t be avoided at all cost.

The alternative isn’t massaging your old system when the technical debt weighs it down too much. The alternative is just maintaining it without improving it, which eventually sees the system overtaken by competitors.

This is a harmful tautology. There really is a such thing as bad code. Some edge cases are introduced by the bad code itself and changing the paradigm can make many difficulties disappear.

Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better?

> Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better?

By learning from their mistakes?

Here’s a famous quote about organizing personnel:

“I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities.

Those who are clever and industrious I appoint to the General Staff.

Use can under certain circumstances be made of those who are stupid and lazy.

The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions.

But whoever is stupid and industrious must be got rid of, for he is too dangerous.”

I would say the 4th class of people are the ones likely to churn out a horrifying codebase. Such people are also unlikely to be able to recognize and learn from their mistakes.

But whoever is stupid and industrious must be got rid of, for he is too dangerous.” I would say the 4th class of people are the ones likely to churn out a horrifying codebase. Such people are also unlikely to be able to recognize and learn from their mistakes.

These are the people that do “negative work”. They cause other people to do more work than if they weren’t there.

Your premise falls apart if you consider the role that management/leadership plays in the process.

I disagree. The quote is for where to place personnel in a leadership hierarchy. A leader without the appropriate aptitude is obviously harmful; but I would say there are actually no grunts in software. Every developer has to lead at least themselves.

> Having the same people who wrote the code work on the rewrite is silly though. How could they be expected to produce something better?

Only if you have really, really poor developers on your team.

Every decent developer learns the pros and cons with how they implemented something. They'll bring that with them to the next time they need to implement something similar. And again, and again.

Not necessarily. I’ve worked with an “architect” who started at the company as the only developer and as it grew became the dev lead just because of seniority. He kept making the same mistakes and was the definition of an “expert beginner”.

He ran away everyone who was brought in to bring some outside perspectives. The only people left are those who gave up and go with the flow because they can’t find a better job without moving (small city with only three major technology employees) and those who don’t know any better.

Or maybe, the edge-cases were there because they were written on top of assumptions that proved to be obsolete.

Yup. I'm in the midst of rewriting a certain part of a robot fleet system. A lot of what we are replacing is obsolete or never needed or poorly implemented. But the first generation was good for its own reason: get a functioning system to market before everyone else and start learning everything about what's right and wrong with the design.

I really hate this cute quote about rewriting because it's elitist (you have to be an expert to do it right) and generally sells the false idea that rewrites aren't a valid part of iterative product building.

Yes, there is often a lot of domain knowledge embedded in that legacy code. The sort of information that is difficult to tease out of the business or understand by looking at the code.

Reply on news.ycombinator.com