[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.