You may have heard that rewriting code from scratch is a Thing You Should Never Do. We’ll critically examine the origins of that proverb and its applicability to modern software development, as well as share some stories and common patterns from successful rewrites.
Software engineering is a complex and contextual domain. Given any question, there’s a good chance that the best answer is “it depends.” Despite this, we still elevate some prescriptions to the level of “common sense” or even dogma. One such idea is “never rewrite the code from scratch,” which traces back at least as far as the year 2000.
I’ve had this proverb recited to me more than a few times by my superiors and peers. Sometimes, avoiding a rewrite has been the right call. But other times, eyes open to the potential issues and strategies to avoid them, I’ve pushed for a new system. Those projects have been some of the most rewarding and impactful of my career.
I’ll discuss the origins of the “never rewrite” idea and why the original reasoning doesn’t always apply to us today. I’ll also present my framework for planning a rewrite and how to capitalize on a successful one. Finally, I’ll share some stories of my successful rewrites and how they improved our engineering teams.
Key takeaways
- Why rewrites are sometimes (but not always) a terrible idea and how to tell the difference
- How to approach redesigning a system from scratch, from pitching the idea through to successfully landing your new system
- Examples of successful redesigns, their technical impact, and the effect they had on their engineering teams
