There is nothing in this word constant but inconstancy.
-- Swift
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.
--Franklin D. Roosevelt
Plan to throw one away; you will, anyhow.
One of the worst
habits that we as programmers pick up in college computing classes is that of poor
software design. Almost every project written in a computer class is '
throw away code'. We
write the program, get it working,
document it, hand it in and that is the last of it - the code is finished. That is it, the assignment is finished. The
bugs found and learning done in
debugging discovering fundamental mistakes that were
patched around did not go back in to the
design.
In the real world of software design, when someone writes a program for the first time, it is often built on at least one flawed design that is discovered later into the project - some assumption that was made turned out to be wrong and caused a cascade of changes throughout the program that made it messy with convoluted logic.
The classical method for software design is:
Plan (1/3) -> Code (1/6) -> Component Test (1/4) ->
System Test (1/4) -> Delivery -> Support.
This model was proposed by Winton Royce in 1970 and provides for some feedback from a stage to its predecessor, but limiting it to the immediately preceding stage, thus keeping the costs and delays contained. This classic design can be found in DOD-STD-2167 (the Department of Defense specification for all military software).
One of the fundamental flaws with this method is that things aren't put together until the end. Difficulties in design cannot be sent back to the 'plan' stage. The basic fallacy with this is that there is an assumption that the project goes through this process once. This assumes that the foundation upon which it is built is excellent, the implementation is superb, the code is sound, and any bugs encountered are fixable in the testing time. In other words all the big whammies are recognized in the planning stage.
By planning one to throw away once the tests are done, you go back to the beginning and start over with the new realizations that have been uncovered. This time, building it the Right Way. The second time, it should all go smoothly and thus should not be a major impact upon the overall design time. The cleaner design will mean more efficient code delivered, and much more maintainable code. A 'win' all around.
Quotes, title and idea from The Mythical Man-Month