The other day, Elon Musk and George Hotz mentioned that Twitter would probably need a full rewrite to get to the place where it could reliably and quickly ship new features. There was a lot of pushback from the infrastructure side – many developers who either maintain legacy software for a living or were the ones who originally wrote it. Two laws often cited –
- Chesteron's Fence – Don't take down a fence until you know why it was put up.
- Gall's Law – you cannot design a complex system from scratch
Rewrites are a hard sell to customers: why should they switch to another platform (with minimal enhancements) when they're already using a product? It's easier to sell new features and improvements to existing clients than it is to sell a different product.
It is also difficult to objectively compare the original and rewrite, as both products will share some DNA (i.e., the same core architecture or design). In practice, it's usually easier to measure incremental changes (magnitude over timing).
But sometimes rewrites are necessary.
Sometimes the market changes, and a new architecture is needed. That might be a shift from on-prem to cloud (or cloud-prem). It might be a heavyweight and centralized stack vs. a serverless one.
Sometimes it's hard to hire for an outdated technology stack (e.g., why FORTRAN developers are highly paid).
Tooling Changes – while developers today have it pretty good with great tools like Kubernetes, Docker, Helm, and countless other projects, these weren't around 5 years ago. Sometimes rewrites make sense because the developer experience has improved drastically since then: better monitoring tools; stronger security primitives; new technology stacks that weren't previously applicable (e.g., cloud computing).
So does Twitter need a full rewrite? I don't think it would solve Musk's goals (which, I'm assuming, is positive free cash flow and increased growth). Some actual alternatives to a full rewrite (assuming you're inheriting a poorly written codebase that you must rewrite):
- Selectively import data into a new app experience – e.g., a separate Twitter Blue built on a new stack. It would still rely on "legacy" APIs but might be able to abstract them away enough to take advantage of a new architecture. For example, there's probably something to be gained by only importing the Twitter social graph into a new experience (e.g., spaces) that doesn't need to interact with the main app otherwise.
- Selectively rewrite services – pick the biggest bottleneck (e.g., Timeline service) and rewrite that.
- Delete code or features – one goal of rewrites is to remove complexity, and removing features or code achieves this. It's easier to delete code in place (and test for equivalence) than it is to rewrite (and potentially introduce new bugs).