Generalizing "Plan to Throw One Away" for Large Projects

scrottie on 2004-11-16T12:30:29

The same friend is a perfectionist but also believes subconciously in a sort of pre-ordination and a perfect path. Everything must be done perfectly. He can't make the wrong choice. He'll avoid it at any cost. He gets frustrated programming because his programs don't work. Specifically, he tries to build something complex but has a hard time when he starts off on the wrong path and gets down on himself and depressed. A lot of novices have this problem but this person has been at it for years and years and hasn't shaken this. This note is my explanation to him of how software development works. The description was an attempt to get him to relax and accept things.

It takes about six passes to get a medium sized program correct: the fist pass fails completely but you discover how not to do it; the second pass is awkward and obviously headed the wrong direction but doesn't exaclty miss the mark either; the third pass is workable but gives you ideas for how it should really be done correctly; the fourth pass works and fits your mental model but isn't documented well and doesn't fit other peoples minds outside of the authors; the fith pass (in maintence) finally gets it right.

This is before questions of adapting the code, making it robust against refacting and change, and generalizing it for other purposes come up. Development is an iterative process, and making mistakes and learning from them with rapid turn-around is critical. Unlike engineering fields, there are no manuals that describe in definate, scientific terms how to succed the first time, successes are all relative and are merely slightly improved versions of failures with "success" being an arbitrary point where iteration was stopped. And history seldom reflects well on the point that the decision makers drew as the "success" point - after some time, most software seems really bad.

-scott


Evolutionary Prototyping

schwern on 2004-11-16T21:25:22

Rapid Development has some good summaries of several iterative programming practices including one called "Evolutionary Prototyping which can be thought of a "write one to not throw away". Its a method of starting off with a prototype and morphing it into a working product without having to throw it away. RD was written before things like XP and Refactoring were popular so they're not explicitly mentioned but they'd fit right in.

For a perfectionist who doesn't want to admit that their path is wrong, EP might be easier to swallow. They're not going in the wrong direction, they just need to bend a little...