Tuesday November 16, 2004
Generalizing "Plan to Throw One Away" for Large Projects
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
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