🚀 go-pugleaf

In article <gUg4szy00UhTxdA0VA@andrew.cmu.edu> rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes:
>That's the problem. Many programmers are completely ignorant,
>unaware of, or simply don't care about the people who will
>be using their software. ...
> ...  He's an excelent programmer.
>THe prob is, the applications he's doing are for scientific 
>research, and he has VERY LITTLE conception if the needs
>and requirements of the people who will be using his software!
>

Then I guess that is all he will ever be is a "programmer"  (As opposed
to what?  Read on...)  This is an ever increasing problem.

>
>It's my belief that a programmer should have a fairly good idea
>of the needs of his audience, whether he's writing a word
>processor to be marketed, or whether he's writing custom,
>one-shot, in-house software. ANy other way is foolishness,
>and programs like MS Word suffer from this lack of vision.
>
>Any comments?

First, as a professional software engineer, I agree with you whole-heartedly. 
A "programmer" is a person who writes code, nothing more and nothing less,
a trivial task given the practice requiring no formal training, just some
cleverness, patience and determination.  A "software engineer" usually 
was once a programmer who received additional training in project management,
requirements gathering, designing and testing.  The end goal is being able to
adequately implement a project in an organized manner and deliver what the
user domain requires with a minimum of waste.

The sad state-of-mind is that the project = writing code and if more code
needs to be written, then we just throw more programmers at it.  This leads
to poor documentation, poor structure, inadequate testing and basically a
garbled mess that cannot be maintained or improved.  A properly engineered
project is the exact antithesis of this state.

This become increasingly obvious on larger projects (> ~100K lines), but
is noticeable on smaller projects as well.  The methodologies work for
ANY size project. For extremely small projects and development teams,
some of the formalism can be dropped; for large projects, it cannot be
done without.  I propose that many of you who are developers do a loose
form of this methodology already; it is only common sense.

Anyone interested in sources to find out more about this methodology can
respond to me personally and I will provide some references.  I suggest
that if you wish to flame me, you send me mail.  This is a Mac group and
not the proper place to debate software engineering.

Jeffrey A. Hallett               (hallett@ge-crd.arpa   hallett@desdemona.uucp)
Software Technology Program
General Electric Corporate Research and Development

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The needs of the few outweigh the needs of the many"

                                 -- Kirk  (STIII)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer:  My opinions do not represent my employer's, but it is his fault 
             for giving me this thing.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~