[weinzierl]

I'm not so sure about software engineers. We often value working solutions even if the code base is not perfect. I certainly do and I very much agree with Joel Spolsky in his classic:

"Things You Should Never Do, Part I

"They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch."

[1] (Emphasis his.)

Where I'm 100% sure is that consultants hate code. I've never ever seen one recommending the reuse of existing code - not once.

And it's understandable: They have nothing to gain from recommending reuse of existing code.

In the best case the code is good and everything else goes well and the client saves some money. If the consultant can not pull this of repeatedly their benefit will still be limited. The praise will be with the programers.

On the other hand, if the old code is bad or anything else goes wrong everyone will blame the consultant for the recommendation.

For the consultant it's a risk-return tradeoff that just always favors a rewrite from scratch.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[andix]

Im a big advocate of rewriting code from scratch. Because on a rewrite you have a much better starting point. You have a (mostly) working solution, you understand the problem much better than on the first attempt, you have some tests and some data. Most of the time you don't rewrite it 100% from scratch, often you can copy a lot of code from the old solution.

To utilize all those benefits you can't rewrite everything at once from scratch. You need to do it incrementally.

[jvans]

The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very easy to overlook

On incremental improvements you should be able to stop what you are doing within a week or two and be ok with leaving the code like that for a long time.

[hinkley]

The main value a big bang rewrite has is that for six to eight months the dev team gets a break from being asked a lot of uncomfortable questions. By the time the questions get properly uncomfortable again, you’ve worked there long enough for it to be reasonable for you to leave.

Incremental improvements require more skill. The sorts of skills that make you a better developer. So even though it’s more difficult, it’s much more valuable to all parties for you to attempt it.

The only reason for a rewrite is when you have a language or framework that’s dead, and there are often other dynamics that put you in that spot in the first place.

There are a bunch of common mistakes people make with trees that take years off their life expectancy. The worst guarantee the tree will be dead in twenty years (and potentially dangerous before that). Software has similar phenomenon, on a much shorter time scale.

[jvans]

I am sure there are good reasons for it, the postgres proposal for switching concurrency models[1] comes to mind. I actually just posted this question to see what people come up with: https://news.ycombinator.com/item?id=36646299

My knee jerk reaction to rewrites is so negative I actually would like some counter evidence on when it worked out.

[1]https://www.postgresql.org/message-id/4658520e-5cd0-6242-e54...

[ficklepickle]

We're in the midst of a couple rewrites that are going/have gone well. Perl to golang and angular1 to react.

The common factor is doing it gradually, basically page by page. There is no big switchover, new code goes live as it is ready. We have some very competent people with long tenures which surely helps.

[parineum]

I'm not a usually a huge fan of buzzwords and I usually give trends time to pass before bothering with them but this is an advantage of micro services that I really like.

[aledalgrande]

What you are describing is called "refactor" not "rewrite". Incremental changes that use existing code don't allow for great changes in the architecture.

I'm not against rewrites, sometimes the company grew so much that you need to start from scratch and rethink given your current knowledge. Or you started with a low fidelity prototype and you rewrite to create a production ready feature, without the crufts in the design you had when you started.

[andix]

It's also possible to incrementally change the architecture. It doesn't have to be a Big Bang.

Edit: refactoring is usually considered to be done on existing code base. I really mean thowing a whole component away and re-doing it from scratch. The components need to be small enough though, that you can deliver them to production within 2-5 months.

[aledalgrande]

Yes, it's not a black and white situation.

[lisasays]

Of course Joel was wildly hyperbolizing, to the point of absurdity.

Code gets re-written from scratch all the time, for perfectly legitimate reasons. As even Joel Spolsky knows. He just meant that you should be aware of the trade-off, and that most of the time, you probably don't want to re-write from scratch.

But "Never do X" sounds much catchier. And succeeded in getting the article shared and quoted infinitely and endlessly, to this very day.

Even though everyone knows it isn't, you know, actually literally true. Even Joel.

[jvans]

I don't think this is hyperbole, i completely agree with it as written