The statement "Don't be afraid to start over" seems obvious to the breed of programmer today who starts off assuming that they will always throw away the first several versions of their program. There is some indication that this idea of rapid prototypes followed by several revisions, starting over from scratch, produces good results in the long run. OK I don't buy it but then I haven't really tried it.
This proverb was originally written at a time when rapid prototyping was barely even thought of and starting over from scratch was a difficult idea for many to get their heads around. Of course even today it is hard for some people to give up on a piece of code after they've put a lot of time and energy into it. The truth is that sometimes once you get into a program you realize that some important things were not thought of during the planning process. Sometimes you have a piece of code that you can modify easily and fit the new code in nicely. In the real world though more often that can be very hard. There comes a time when banging and beating a piece of code to include new things is not really a good idea.
The thing that gets me interested in starting over is how big a mess the code becomes when new features or functions are added - or attempted to be added. Maintainability of code is a big deal to me. When the costs of maintenance will get too high using the current code base it may be time to think about starting over. Hopefully all the things that were learned the first time will make the second version a lot easier and faster to create.
[Note: I am away on vacation this week so I decided to finish up this series and have these posts show up while I am away.]
This is the twenty-sixth and final of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
I have enjoyed this series I am compelled to weigh in on this final post.
I find that in commercial products rewrites are a difficult feat. Usually the inertia of a commercial product and unyielding demand for new features makes starting over from scratch very difficult. The best corporate scenario I've encountered enabled us to start again only for a particular module at a time; and even getting priority for those projects was difficult.
Fundamental to the notion of starting over is abandoning backwards compatibility. Sometimes that means removing a feature, or significantly altering its behavior. And when you have a large customer base relying on those features it can be a hard sell. This is what I attribute to the steady growth of many codebases (windows comes to mind specifically).
In non-corporate settings starting over is easier because the pressures of backwards compatibility are often mitigated.
Personally I've found starting over to be an excellent way to maintain a clean and flexible architecture. A friend and I started a complex jukebox system 6 years ago and I've completely re-written it three times since and have been increasingly pleased with the results.
The most interesting thing I noticed during the most recent re-write was that there were aspects of both the first and second versions that I kept. I was surprised that the second version wasn't completely superior to the first, there were some new limitations that I'd introduced which could not be easily seen when v2 was first written.
The most valuable lesson I learned learned from re-writing the application from scratch was a much deeper understanding of the benefits and flaws of the original designs.