Why your programmers fantasize about a big rewrite

I believe the appeal to be (though fallacious) that with a ground up rewrite you already have an entire functional specification of the system you need to build. No need for annoying customer engagements, requirements analysis, spec-ing, scoping, etc.

With these rewrites do you just abandon maintaining the legacy system and focus on the new one?

I find it immensely more satisfying to "rewrite" a system using the Ship of Theseus approach (aka Strangler Pattern). If there are no tests, the first (and exciting) challenge is to put some behavioral tests in place in an attempt to protect it from the changes you are about to make.

At the most basic level though, I suspect it merely comes down to:

Building something new is fun, trying to debug, build on or debug something that already exists is a lot less so.

Well that and the point in the article about how their ideas would be respected. The guy who builds a whole new system gets a lot more respect from the management team than the person who keeps it going or fixes bugs.

the vast majority of rewrite movements I've observed or been part of are clearly, unambiguously due to the fact that:

- the legacy system is a spaghetti code nightmare - with arcane and manual deployment process - years of band-aid hacks layered over every component - inseparable two-way dependencies across all bounded contexts - inscrutable data structures - nearly impossible to debug - utterly fragile and mostly undocumented - riddled with dead code and unused components that merely confuse the poor soul tasked with debugging - often so intertwined with dependent systems that there's a dev "environment" shared across programmers because no one can develop on their machine.

THIS is why your programmers fantasize about a big rewrite. Every time.

I have at some time or other agreed with pretty much every view here, ranging from:

  - full rewrite replacement
  - piecemeal separation of a function (e.g. search)
  - in-place migration to a desired design
  - side-by-side incremental replacement of functionality

Each has it's merits, although I tend to believe developers lean toward remaking everything themselves and thus try to consciously give more consideration to alternatives. The most interesting is the side-by-side one where we could run non-mutating requests through one (Ruby) or the other (Go) for performance measurements, or through both for correctness comparisons monitoring all metrics during the migration.

Rewriting software from scratch can often be the only sane thing to do when it gets messed up by quick and dirty patches, but doing that using the latest "thing" is the worst mistake one could make: by doing so one would simply swap errors due to bad problem analysis and time constraints with others due to bad knowledge of the new platform, paving the way for the next rewrite from scratch, naturally by using the then newest "thing". Just don't do that; there is no framework/library/language in the world, or any other place in the known Universe, capable of replacing good problem analysis and familiarity with the 10+ years old tools the programmers know best.