When should you rewrite?

When it’s a house of cards. 

Perhaps I’m a little jaded, but I’ve built a very nice career rewriting software that never should have been written in the first place. Of the existing code I’ve encountered, at least 95% would never have passed a code review by me (or anyone else who knew what to look for). 

The problem is that we’re so committed to pass user acceptance testing that we never subject the source code and data base design to the same rigors. 

I like to think I’ve seen it all: one and two character variable names that mean nothing, homemade routines for sorting, selecting, you name it, memory leaks, iterations to nowhere, upward branches to nowhere, data base schemas that would make M. C. Escher jealous, and on and on and on. Face it, if programmers were doctors, we’d all be dead. 

As a constant victim of the “You Can’t Get There From Here Syndrome”, I often tell my clients the same thing, “It’s not how soon we get started, it’s how soon we finish AND how capable we are to handle the next revision”. 

Often rewriting is the last best hope.