Andrew Lentvorski wrote:
It depends. Sometimes yes, sometimes no. If I'm having to be very
exploratory, documentation will be as useless as unit tests. It's a
question of malleability vs. benefit.
Documentation is far more malleable than code is. In one recent project,
I went through four iterations before finding the fifth one that "felt
right." From there, I started coding. Then again, I'm experienced
enough that I can look at a spec and have an idea of how ugly the
related code is going to be.
If you're writing a compiler, not having the language spec figured out
before you start is going to lead to a mess. :-)
On the third hand, when you're working on a project where people don't
know what they want before they see it, or where the specs are changed
without regard to what the system does already (as with the original XP
application), trying to nail down specs before you start is going to
introduce unacceptable delays, and you're going to need to be able to
change things anyway.
Of course, there are obvious exceptions and limitations.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
