When the architecture of a system starts to show its limits, it’s tempting to throw everything away and start from scratch. But a rewrite has challenges too. The existing software is a value-generating asset and must be maintained. The new architecture is unproven and comes with risks. Reaching feature parity can take years, and the rewrite turns also into an integration challenge to inteface the old and the new system. If a big bang approach is chosen, planing the switchover without data loss becomes a project on its own. These are just a few of the considerations, far from an exhaustive list.
Joel Spolsky wrote in 2000 an influential article discouraging rewrites, calling a rewrite the “single worst strategic mistake” you can make. Many developpers know this article and it often cited. Developpers are generally wary of rewrites. I love this description from Tyler Treat:
“Rewrite” is a Siren calling developers to shipwreck. It’s tempting but almost never a good idea
Yet, many software systems are regularly rewritten, as seen by the numerous articles listed below. And many rewrites are successful.
Whether you should rewrite your project or not can only be answered by yourself (or your team). Too many factors impact such a decision to be turned into a decision algorithm. Often, to rewrite or not ist not a binary decision anyway. There are nuances, for instance, which components of the system to rewrite. How much of the old system do you need to replace to call it a rewrite?
Having been working on Smalltalk for some years, I can confirm you that you can go a long way without a rewrite. Indeed, the Smalltak images that we use today are in fact “ancestors” of the very images of the 80s. All changes have been pushed within the environment itself, without a rewrite, even without a restart (because the concept doesn’t exist in Smalltalk).
I expect to hear about a few more software rewrites in my career, because it’s inherently tied to software evolution. A software rewrite might have a negative connotations sometimes, for instance when it’s driven because of massive technical debt. But most software rewrites are driven by increasing requirements. You rewrite your system because you are asked to make it work beyond what it was intially intended for. Actually, it’s the price you pay if your system is too successfull.
MORE
Some stories about rewrites or significant rearchitecturing work that I liked:
- https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
- Hazards And Safeguards for Software Rewrites – Industrial Logic
- Things You Should Never Do, Part I – Joel on Software
- Second System Effect
- The Big Rewrite – Chad Fowler
- https://medium.com/@terrycrowley/arrival-of-the-fittest-be3b8db0d8bf#.7r2yigf6w
- https://drewdevault.com/2018/05/27/Why-rewrite-wlc.html
- https://eng.uber.com/rewrite-uber-carbon-app/amp/
- https://martinfowler.com/articles/break-monolith-into-microservices.html
- https://ckeditor.com/blog/Lessons-learned-from-creating-a-rich-text-editor-with-real-time-collaboration/
- https://signalvnoise.com/posts/3856-the-big-rewrite-revisited
- https://engineering.linkedin.com/blog/2018/12/coding-conversations–interviews-on-replacing-infrastructure-sys
- https://changelog.com/posts/the-many-reasons-replatforming-freshbooks-should-have-failed-and-why-it-succeeded
- https://mobile.twitter.com/johnsundell/status/1018101018805096450?s=20
- https://increment.com/frontend/making-vue-3/
- http://www.bennorthrop.com/rewrite-or-refactor-book/chapter-2-the-risks-of-rewrites.php
- https://slack.engineering/how-big-technical-changes-happen-at-slack/
- https://mobile.twitter.com/StanTwinB/status/1336890442768547845
://ewernli 