Rewrite or Refactor?
Exploring the path of full-scale application modernization


(2 comments)
May 27th 2020


Note: I've been thinking about writing a book on the topic of rewrite or refactor for years now. Over the winter I finally "broke ground" on the project. Progress was initially slow, and now, given the state of things, slower than slow. Rather than wait to finish the book in entirety, I'm going to release it piecemeal and (hopefully!) publish when it's done. Feedback welcome!

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

  1. What do we Mean by Rewrite and Refactor?
  2. The Risks of Rewrites
  3. Why we Rewrite (Even When we Shouldn't)
  4. Good Reasons to Rewrite
I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). In 2018 I started Highline Solutions, a consulting practice that helps companies with architecture, devops, and full-stack development. I have two degrees from Carnegie Mellon University, one in Information and Decision Systems and one in Philosophy (thesis). I live in Pittsburgh, PA with my wife and 3 energetic boys.

Got a Comment?


Comments (2)

June 12, 2020
I love that your proposed O'Reilly-esque book cover contains the image shared by the existing O'Reilly book for Flash Player 11 (https://images.app.goo.gl/Q2dHv15Z3wkkfyit9)
Ben
June 15, 2020
Lol. I didn't realize that. Flash Player 11. That book was a classic! Jk.