Throw One Away In Practice

Problem:

You are messing with unknown hardware or the requirements are still being discovered. The client wants spiffy functionality added to a design lacking stability. You don't happen to have a good, solid piece of lumber handy (TwoByFour) with which to change his, um, "mind."

Solution:

Build a SpikeSolution that you plan to scrap later. Do not put any effort into pretty interfaces and "cool" features until the basic platform acts like a real product. Build up what you need for right now and toss it when it has outlived its usefulness.

Moved from PerpetualNow

I, for one, had an experience similar to the one described in the first section; my little brother had just begun (began? started?) to figure out how the computer worked, and succeeded in wiping all my files from first my backup computer, then the main family computer. I know it was unintentional, as he idolizes me and also can't read yet so couldn't have targeted my files. TMALSS, my (unfinished) novel was one of the things wiped. Fortunately, I had the story line in my head and was able to re-write it from scratch. No sooner had I finished a marathon twelve-hour block of solid writing than my mother hove into sight, bearing a forgotten binder with a complete printout of my story. Reading the printout and then the screen, I realized that my second copy was better than the first.

This might be a pattern for developers who have had previous management fiat move a prototype onto the sales floor - make sure that it cannot impress the customer as is. I'd suggest a lot of useful command-line-driven functionality, that can be GUIfied later --PeteHardie

FredBrooks in TheMythicalManMonth wrote an essay called PlanToThrowOneAway and another essay called "The Second System Effect." (SecondSystemEffect) I don't have the book here (just the contents page from Amazon) but I seem to recall that both these chapters were pertinent here. --DominicCronin

"Throw one away" stems from the BigDesignUpFront approach and reflects the fact that often important details are missing from a paper design. A better approach is iterative development. Change is ongoing, making it impossible to determine when an old version is "thrown away" and replaced with a new one.

Hmm. Why does the idea of tossing an approach out imply that "important details are missing from a paper design?" Could it not be that everybody involved is still in discovery? That a particular implementation matched a particular set of hardware and that now we need to move to a different hardware platform with completely different capabilities? That certain client preconceptions have been eliminated and the client is now open to possibilities that they weren't before?

We can all agree that the ThreeRingBinder approach is not so great. We can also all agree that, regardless of how smart we are or how much experience we have, nobody can think of everything up front. That is a prime observation from XP. Well, why can't the idea of tossing off a SpikeSolution be valid in this context, too?

"Throw one away," at least in the context of "The Mythical Man Month" referred to building an almost complete system, throwing it away, and building it again before the first delivery to the customer.

The thrown-away system could be seen as a very large SpikeSolution.

See: PrematureOptimization, OptimizeLater

Contributors: MartySchrader, TheNakedGuyOnline?, Seanchai, PeteHardie, DominicCronin

CategoryRequirements, CategoryOptimization