Instead of "rewriting from scratch…"

Continuing on from Nobody cares that you “rewrote from scratch”…

There’s a common belief amongst programmers that when confronted with a revolting, despicably complicated codebase with severe quality issues, the best you can do is throw it away and start again. That might have been true once (although I suspect not), but it’s certainly not true today.

First, one has to ask, why is the codebase so bad? Almost always, the answer is due to shoddy processess – lack of testing, no culture of quality, a prevalent cowboy attitude within the coding team (or person). No number of rewrites will make these process problems go away. Software quality is a mostly solved problem today, at least on the small and medium-sized projects I have experience with. We know the solution, although too often it is not applied.

Second, today’s great refactoring tools make it easy to turn bad code into good code. This is especially true in the Java world, where our IDEs runneth over with refactoring goodness. A codebase might seem to have tremendous quality problems, but normally most of the problems lie in a few concentrated areas. Once the biggest problems are identified they can be rectified.

A good refactoring process might go like this:
1. Break up that large, confusing method that keeps crashing into a number of smaller methods, which can be tested individually.
2. Write unit tests for those new smaller methods.
3. Add precondition checks for the methods. For example, check for null inputs or out-of-range values
4. Repeat from step 1 until the problem spot has become clear and simple
5. Repeat entire process with another problem spot

Once you’ve improved these trouble spots, you can claim what Microsoft claims with each new release of Windows: That the latest release is a “new, improved update, more stable than ever”