Chapter 6. The Big Rewrite

Before you embark on The Big Rewrite, I hope you’ve exhausted all other options. You tried refactoring the codebase, but you hit an impasse. You investigated the feasibility of replacing your legacy software with a third-party solution, but it would require so much customization that it would be more work than writing it from scratch. You concluded that there’s no getting away from a rewrite, as much as it makes your skin crawl.

Before we move on, let’s remind ourselves why our skin is crawling at the prospect of rewriting a legacy application from scratch.

First, the project will drag on interminably. I guarantee that it will take longer than you expect. At first, a rewrite can seem like a relatively simple task, as you only have to copy whatever the existing software does. But once you start implementing, you’ll uncover all kinds of weird corner cases and rabbit holes in the existing software (both the implementation and the specification), all of which need to be investigated and documented. Not only does this slow down the project, it also gets pretty dull for developers after a while. Although developers are usually keen to write code, a large proportion of the work involved in a rewrite is laborious investigation and debate about how best to deal with some obscure behavior of the legacy software.

6.1. Deciding the project scope

6.2. Learning from the past

6.3. What to do with the DB

6.4. Summary