Improving bad stuff

At the moment I'm trying to rescue a project that went bad. The problem is one that is very common:

• Initial design is not bad, but simple
• During extension, the design wasn't adapted to new insights
• Things that were added were mostly badly thought out

In this case, I made the initial simple design/implementation. It highlighted some concepts that seemed to be right. Months later I'm stuck with a project that has gone bad. A product of misplaced trust in the developer.

The question is always: adapt or rebuild? My personal experience says: if in any doubt, rebuild. It's amazing to see how many are scared to death to do that. What are they thinking of? The extra typing work? The re-design?

The thing is: however bad the current product is, it always gives more insight in what is needed, and how certain things can be done. See it as a (bad) prototype. Re-do the basic design and fill up the new framework - partly by cut-and-paste of things that can be taken from the old stuff. The other part, well, typing is the easiest part. Lots of people seem to think that you have to cut-and-paste almost everything. But also here: in doubt, simply type the stuff again., probably just a bit different, better. My guess is that during programming, 5% of the time is spent typing the code. The rest is thinking, checking, switching, debugging, testing, ...

The nice thing is I've quickly made a new specs wiki in a matter of hours (the old one wasn't a specs wiki at all, with useless stuff all over the place). Now I just need to get a new basic implementation in place, and then go through the check list to get the whole thing into a better state. One in which the product will actually work, and can be improved to become a great product. Luckily, this is an internal project, if this would have happened in a project for a client there would have been some painful explaining to do ...