On Mon, 09 Feb 2004 03:54:09 GMT, "Doug Kanter"
wrote:

~~snippity do da ~~

In a correctly ordered software project, the processes I described are not
done by tech heads. As you said, this usually spells disaster. Requirements
gathering is a dialog between designers and the intended user population,
with programmers left OUT of the loop for the time being. Ideally, designers
are people who know what the programmers are capable of, but that's the
extent of their involvement with programming.

Again, I agree. The wrinkle is when you design a piece of software
(by design I mean set up a set of specifications - I want the software
to do this and this...etc.). Once it gets to the technoids it becomes
a fight between the hardware folks ("that's not a hardware function -
it's a firmware function"), the firmware folks ("that's not a firmware
function, that's a software function") and the software folks ("Well,
we can do that but you have to change the specifications because the
software won't do this and this and...oh, by the way it will take at
least a year to eighteen months unless you get the hardware to change
this and firmware to do this".

Been there, done that. :)

The design process in most pure software projects is alo a train
wreck. Programmers are given a set of specifications, the wrangle
about what can and can't be done begins, marketing gets involved,
first run gets to the customer who goes "what the f---?" :)

Back it goes for Rev: 1.1.

Been there, done that. ;)

Of course, the answer is good solid engineering management, but the
managers are busy with personnel reports, turf fights, personality
conflicts, political fights, avoiding tough projects, answering
questions from on high, writing evaluations, that they dont' have time
to keep up with the technical stuff and get into the "make it go away"
mode.

Been there, done that. :)

In a perfect world, you would be on the mark. There ain't no such
thing.

~~ snippity do da ~~

It's also a somewhat concept becuase it is "open source" only to those
who understand the coding structure - thus the end results will be the
same.

Exactly, but worse: Many of the contributors to BIG open source projects are
children. Literally. Teenagers who think it's cool to see their defective
code included in something famous. But, they never got the message about
gathering requirements first.

LOL!!!! Man, I could tell you stories....

I don't know if you enjoy computer books or not, but the bible of user
interface design is quite fascinating. It's called "About Face 2.0: The
Essentials of Interaction Design", by Alan Cooper. When you're done with
it,
you'll know exactly which software authors belong in hell for all
eternity.

I'll look it up - thanks for the tip.

The above book is a good read for users, or people involved in software
construction. Cooper was responsible for the design of Visual Basic, but he
still takes plenty of pot shots at his old employer. It makes the book fun.
Here's another that would probably put most users right to sleep, but it's a
classic:
"Exploring Requirements - Quality Before Design", by Donald C. Gause &
Gerald M. Weinberg. It's a $44.00 textbook, but many libraries have it,
usually covered with dust. It's a real eye-opener because it makes it quite
clear which software firms missed the boat entirely.

Something tells me I've read this at some point. I'll go down to
UCONN and look it up. It's on the list - thanks for the tip.

Well, once I finish making up this years set of jigs, tubes and
fishign rods, I'll find time to read it. :)

See, that's the thing about being retired - you are about as busy as
you were when you were working.

Only it's more fun.

Later,

Tom
S. Woodstock, CT
----------

"To the fisherman born there is nothing
so provoking of curiosity as a fishing rod
in a case."

Roland Pertwee, "The River God" (1928)