Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)


My email address is Spam me harder! *moan*

Journal of scrottie (4167)

Tuesday November 16, 2004
07:30 AM

Generalizing "Plan to Throw One Away" for Large Projects

[ #21877 ]
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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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