Evolution vs. Revolution

In my previous posts, I have been arguing the point that throwing away source code and starting over from scratch is a notably bad idea in general. In this, I am echoing what Joel Spolsky says so eloquently in his post Things You Should Never Do.

(Incidentally, I just observed the zero-filled naming convention that Joel is using in the URLs of his posts. This is post number 0000000069. Either Joel is expecting to be astonishingly prolific, on the order of tens of thousands of posts per day, he is expecting to be outlandishly long lived, or he really likes the number zero.)

I think it would be unfortunate to interpret this sentiment as being absolute in any way. Quite simply, there are some situations where it is, indeed, appropriate to completely write from scratch. The only question is, how do you decide?

A good example to consider is the revolution that took place in aircraft engines. Originally, we used propellers, and now we have the option of jet engines. The move to jet engines was anything but an evolution. Rather, their designers began with a clean slate. In fact, had they worked under the constraint that they must begin with a propeller engine, and gradually make changes until it became a jet engine, it would have been much more costly overall. Biological life has the constraint of natural selection. You begin with a certain organism, and you can gradually evolve it. At each step, the organism must have equal or better survival characteristics as the step before it. Had we applied the same constraint to jet engines, then engineers would have been required to develop a series of engines evolving the propeller to the jet, each of which would succeed in the market place.

Fortunately, they did not operate under that constraint. Your software does not need to either. So, evolution and revolution are both tools that you have available to work with the software organism, and making intelligent decisions regarding the best approach is absolutely critical.

This truly is the trick, then. If the code you are writing actually exhibits an identical phenotype as code that already exists, then you are fundamentally wasting your time. Observe what happens, in the world of natural selection, when two genes exhibit identical phenotypes. The genes that are present in the majority of organisms, no matter how small that majority is, will eventually have a dominant position in the gene pool. By creating new software DNA to exhibit the same phenotype, you are most likely wasting your time because you not only divert resources from creating new functionality, but that code is doomed to obscurity and eventual demise. You lose an opportunity for achieving immortality through your software - and isn't that part of the fun?

Propellers have fundamental limitations that justified the investment in developing jet engines. No matter how carefully the designers worked to evolve the design, they simply could not achieve the results they needed without taking a different approach altogether. Is there a fundamental limitation in the nature of the software you are creating? Can it be evolved and refactored, or should it be completely reengineered? And, if you need to engineer a different solution altogether, you should choose the smallest necessary piece to re-engineer. With the advent of the jet engine, parts of the plane needed to evolve to support the new engine design, but the concept of the plane itself could be evolved, rather than re-developed from scratch.

Comments (4)

  1. Travis Owens says:

    Well on the issue of throwing away old code and start anew or fixing old code….

    It actually differs, overall I’d say fixing old code is the best thing, even if it’s possible more work than starting anew. At least with a OO language you should be able to rewrite the code and keep the app working as you refactor. If it’s an older scripting language, it may not be that easy.

    Despite, my point is, if you were the original author and you are going to throw away the code, you should slap yourself on the wrist for writing something so bad in the first place. Of course chances are you are repairing code you wrote as you were learning (but then aren’t we always learning).

    If it’s somebody else’s code, well the code could be so bad that you might not have a choice. A coworker had to repair a project that was VB.Net code gen from some custom tool. We didn’t have the tool or the original specs that generate the code, we just had the generated VB.Net code. In the long run the app was better off being rewritten as the project went horrible and only 1/5th of the features they needed were added as the code gen architecture is in such a serious need of refactoring, it hurts.

  2. Travis Owens says:

    By the way, that article was a very enlightnenig read, while I haven’t done it yet, I will admit to being in the "rewrite it from scratch" camp but thes article really opened my eyes.

    I won’t be so quick to rewrite code next time, I’ll give porting code a more serious attempt.

Skip to main content