17 Dec
2001
17 Dec
'01
5:08 p.m.
The book by Brooks {The Mythical Man Month)should be mandatory reading for
every software man. It is fun too.
I have very good memories from projects where you could first build a useful
small part of the system. The client could then update his requirements and
you could get all the bugs out and when all was stable you would build the
next part of the system. The client has a useful system very early in the
project and because you work together with the client (the user) in an early
stage of the project, errors in the specification and the programs never
last long. Cost control is also facilitated. You have a satisfied customer
most of the time during development and very much so in the end. This was
for projects for up to 1.000.000 lines of code.
Wim
----- Original Message -----
From: Chris Kennedy <chris(a)mainecoon.com>
To: <classiccmp(a)classiccmp.org>
On Sat, 15 Dec 2001, Jim Davis wrote:
IMHO: All software development should be
performed as such:
1) Requirements - what should it do, and not do. Spin this till
everybody signs off.
<snip>
Ah, creationism (see the Jargon Dictionary if you're not familiar
with the term).
What is describe is all very textbook. That, then begs the question,
"why is it that software isn't, in general, done in this fashion?".
The answer is found in step one: the assumption that innovative
hunks of software can be fully specified in advanced. For software
that is truly innovative this is empirically very rarely the case,
as what the customer _thinks_ they want is frequently not what they
end up wanting/needing in the end. Trotting out signed-off specs
in no way improves the situation.
In practice the solution is to accept the fact that specs, no matter
how much they are labored over, are for most efforts soft, and
then describe mechanism to deal with uncertainty as part of the
development process. Rapid prototype, stepwise refinement,
the understanding that one cannot test their way to correctness and
a willingness to throw at least one implementation completely
away, coupled with small, agile teams that work with an active
user community empirically produce more correct results in less
time that alternative techniques.
Not like any of this is new. Brooks described this eons ago
in _The Mythical Man Month_...
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
-----Original Message-----
From: owner-classiccmp(a)classiccmp.org
[mailto:owner-classiccmp@classiccmp.org]On Behalf Of Jeffrey S. Sharp
Sent: Saturday, December 15, 2001 8:51 AM
To: classiccmp(a)classiccmp.org
Subject: Re: "Geeks" and licensing
And possibly add some planning where you use historical data and basic
statistics to figure out how big the product will likely be, how long it
will take, and what resources need to be allocated to complete it.
For safety critical, you should /have to perform
statement and
decision coverage in step 6 and 7 and the detailed design should have
a one-to-one corespondence with the detailed design document. Jim
Davis.
The software process course I just got out of also heavily pushed peer
review of designs and code as a way to filter out defects before testing.
These have their benefits, but I remain unconvinced of their status as the
great panacea of software engineering that the course touted them as.
For a little bit of on-topic goodness, what is the group's opinion on the
trend of software engineering quality starting from ancient times? Have
we improved (practially, not academically) or worsened?
--
Jeffrey S. Sharp
jss(a)subatomix.com