Not a real book cover...yet :)
If you're a developer at even a small organization, then most likely you work on a legacy system for at least some of your time. Maybe it's a decades-old Java EE monolith with hundreds of thousands of lines of code, or maybe just a small IOS app built a few years ago with Objective C instead of the latest Swift.
In any case, over time that system has almost inevitably succumbed to entropy. It's become harder to add new features, stamp out bugs, keep performance snappy, or even just apply the latest patches or updates. This can be frustrating affair for everyone, business and technology. And so you've probably asked the question: rewrite or refactor? Is it worth it to keep mending and enhancing the existing code base, with its all its warts and flaws, or would it be better to just rewrite it all from scratch?
Every few years I find myself at this exact crossroads. And more often than not, I consult the wisdom of my always-ready advisor: google. I plug in the search terms "rewrite or refactor", and then get bombarded with countless blog posts, forums, and articles weighing in with their two cents. Don't ever do it, some say. Or rewrite everything to microservices now! It's a complete mish-mash of advice, from the rigid and polemic to the naive and overly optimistic.
What I've always felt was missing was a balanced, technology-agnostic, pragmatic approach to navigating this challenging, crucial, and ubiquitous question: are we justified in rewriting an existing system from scratch, or we should refactor it in place, or some solution in between? And so this is the goal of this book. Having survived (and in many cases pulled off) a number of rewrites over my career, I wanted to share my perspective in hopes that it might help other developers out in the same boat. So let's get going...
Part 1: Building the case for a rewrite
- What do we mean by Rewrite and Refactor?
- The Risks of Rewrites
- Why we Rewrite (Even When we Shouldn't)
- Good Reasons to Rewrite
