Start From Scratch

Sometimes, when an application has suffered from lack of design and from being patched by numerous different people over a period of time, it becomes a SpaghettiMess? and you can save time by starting scratch rather than adding yet another patch.

Often management does not understand this approach, believing that it always costs more to StartFromScratch than it does to just fix the problem at hand. One solution to this problem is to RebuildInSecret? which can be effective if the budget for fixing the problem is enough to cover starting from scratch.

In reality, of course, you aren't starting from the same point that the original programmers did. You have the existing design to copy and the experienced users who can answer questions about HowThingsWork?.

I have successfully applied this tactic to code that I inherited from a team of TransientProgrammers?. For the first couple of programs I did RebuildInSecret? and after that point I was able to convince management that this was an effective strategy.

My very good friend, and, at the time, boss, JohnVenable, gave me a system to implement when I started at Raytheon: convert a C shared memory algorithm to a C++ one. I was not to redesign; instead, I was ordered simply to wrap the C code in a class for use in a distributed system (so my prototype turned into the CORBA interface for shared memory).

Looking at the C code made me blanch: there were if-tests five+ levels deep; there were functions that went on for five pages each. The currently existing system was bad-ugly.

But, quoth John: "Do NOT rewrite the system; wrap the existing code in a class!" I responded, "Yes, sir." and rewrote the system completely. The nested-ifs were refactored into helper methods or discarded, functions went from five pages to five lines, names changed from #shm_attach and #shm_detach to #get and #release in class SharedMemory.

I turned in the task days before the deadline; that was my first project at Raytheon. Sometimes it's cool to StartFromScratch

-- DouglasAuclair

I've noticed that when something is very short (a small poem, a small method/function, a small quine, a screwdriver) people don't have any problem with re-typing the the whole thing, making minor modifications all over the place (perhaps glancing at the original to remind them of the crucial details, to make sure the rewrite isn't worse than the original, etc.).

But when something is very long (a book, a 2 page function, a large program, a drill press), people hesitate to make any changes -- even tiny minor changes, far smaller than the changes they have no problem with in a small function. Perhaps because they can't hold the whole thing in their head, so making some small change is seen as "risky" because they can't be sure they've caught every place that depended on it being the "old way" and changed every single one of them to the "new way".

I remember some sysadmin telling me they learned that it's all too easy to get carried away browsing around on a partially broken machine, trying to discover the single thing that's broken and fixing only that one thing. Sometimes it's better and much faster to back up user data files (burn to CD), erase the entire hard drive, and re-install everything from scratch.

-- DavidCary

[EditHint: Is StartFromScratch really just a synonym for PleaseReinventTheWheel? Should the 2 pages be merged, with one page a one-liner simply pointing to the other?]

Negative. That page has a different flavor to it; these are similar, but not identical, expressions. However, it may be possible to merge the pages under a heading like ReasonsToReinventTheWheel or some such.

See: PlanToThrowOneAway , ReinventingTheWheel , PleaseReinventTheWheel, RidiculousSimplicityGivesRidiculousResources, BurnTheDiskpacks