Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!rmac
From: rmac@well.UUCP (Robert J. McIlree)
Newsgroups: comp.software-eng
Subject: Re: American Programmer
Message-ID: <5474@well.UUCP>
Date: 19 Mar 88 18:39:22 GMT
References: <555@psu-cs.UUCP>
Reply-To: rmac@well.UUCP (Robert J. McIlree)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 54

In article <555@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes:
>
>Perhaps what is most amusing is the universal agreement that "management"
>(whoever they are) is to blame.  The general feeling seems to be that if
>only managers would let us programmers have our head, everything would be
>right with the world.  In the first issue of American Programmer (a new
>magazine that Ed Yourdon is publishing out of his Mac II and office in NY)
>this issue is dealt with as frankly as I have seen so far.  Yourdon points
>out that the average programmer isn't all that great anyway, and should
>share at least part of the blame.  This is no doubt due to the great influx
>of people who wanted secure, high paying jobs in the early 1980's, but who
>really weren't cut out for writing software (I must have taught 500 of them
>from 1979 to 1984, at various universities from Missouri to Oregon).
>
No argument that programmers should share part of the blame for failures.
I think the majority of blame *does* lie with management, though. 
Realize that software projects are, more often than not, political
ventures as opposed to technical ones. Programmers, like all other
employees, need *direction and guidance* at various intervals. Who
is to provide that? Large software projects need organization, planning,
and expertise in various capacities to come out right. The programmer
is only part of the solution.

What do we have in a project besides programmers and managers? System
test people, technical support (both internal and external),
documentation/tech writing, secretaries, clerks, and system
engineers immediately come to mind. Examining what went wrong
on a particular project involves more than looking at the
bugs and inadequacies in delivered software. Defects must
(and can) be traced to various phases of the software lifecycle
that programmers have little to do with! Like requirements
definition, test plans, effective management and leadership
of the project team, and so on.

As to the 500 or so people you mention that weren't cut out for writing
software, how many were writing software after they graduated? I'd
take a guess that a good number of them went to positions similar
to those mentioned above. What formal instruction did they receive
at their institution to prepare them for a software QA, system
engineering, tech writing, or tech support job? Did the CS
departments in which you were affiliated with even approach these
subjects? Or is it left to those one-day to one week seminar courses
employers pay for to turn BSCS grads into one week wonders of system
test?

To summarize, programmers represent a portion of the solution in
delivering high quality software systems on-time and within
budget. They, like any other resource, are controlled by managers.
When placing the blame on project failure, one must also analyze
the other components of the solution, the other groups involved
in that effort, and their management. You'd be surpsised at
how many failures *do not* involve the prgrammers.

Bob McIlree
(ihnp4, lll-crg}well!rmac