Let's Rewrite Everything

The reality of rewrites is that they're often blamed for all of that, while the issue is not the rewrite. The issue is that companies that write bad software will, if given an occasion, write bad software again.

The issue with rewrites is actually that they're not large enough in scope. When you rewrite software, you should probably also rewrite contributors' interactions, the way the company handles power dynamics and, occasionally, the way accounting works at that company. Short of systemic changes, rewrites are likely to fail. But again, the company is also likely to fail other initiatives aswell.

Rewrites that fail in an isolated way are few and far between.

> Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention.

OR it might be a dumpster fire that drives your engineers away, one that is fueled by unreasonable deadlines and expectations. Also good luck refactoring your codebase at snail's pace with noncomitting approval, on your own unpaid overtime.

Citation needed.

All of these is based on random internet wisdom (e.g. Joel's condemnation, based on a different era, different delivery model, and different concerns than most of today's startup and enteprrise code), and anecdotal evidence.

Well, talking of anecdotal evidence I've seen lots of succesful rewrites, that made the thing faster and better.

Heck, most/all of the FAANG stacks are rewrites. Twitter, for example, as you've mentioned yourself, is not the same program that needed restart every day to avoid a memory leak back in the 00s - they rewrote it. Reddit is not the original Lisp, and so on.

It's also about the scope. You immediately undestood "let's rewrite the whole company code" and advise "don't rewrite the whole project". Well, who said it's "a" project to begin with?

Companies more often than not have tons of different services, and rewrites can be easily done for such isolated services (e.g. like the dl.google.com rewrite into Go).

Tons of core services of YouTube, CloudFlare, Google, Facebook, and tons of others have been rewriten with languages as Go, Rust, Hack, etc. and they have written about the experience and results as a success. And it's not like survivor bias, e.g. the keep mum about failed cases, because we hear about failures all the time (just not concerning rewritings).

- The application was complicated, - The application was written in Ruby, and he didn't like Ruby. - Golang was way cooler.

Fortunately our director pointed out that there was no customer value to a rewrite, so the idea was shelved.

However, I would say that Job #1 is to identify what the end users (and the customers if the two are different) think this does. Reproducing the system they use/ paid for is the important goal of the rewrite, by definition if you can't fill that role you failed. Technical considerations (it would be nice to have Continuous Integration, it should be in C# not Java, it should run in the Cloud) are necessarily less important.

If you currently have little or no documentation this process produces valuable documentation and it concentrates you on what's important versus unimportant in a way that studying the existing software as a programmer does not. The trickiest code in the software could be so vital that without it your rewrite is useless or equally never used and you can't figure that out by staring at the program's code.

Once you have that high level you're in better shape to drill down and then I think you're in a better place to figure out if a rewrite is appropriate versus maybe you can refine the existing software.