MDAY@XX.LCS.MIT.EDU ("Mark S. Day") (03/15/88)
Soft-Eng Digest Mon, 14 Mar 88 Volume 4 : Issue 21
Today's Topics:
Why Software is Different (7 msgs)
Whistleblowing and Responsibility (4 msgs)
----------------------------------------------------------------------
Date: 9 Mar 88 18:01:19 GMT
From: bunker!shap@yale-zoo.arpa (Joseph D. Shapiro)
Subject: Why Software is Different
As one who advocates carefully planned and controlled software
projects, I offer the following observations on why some projects are
run on a crash basis, and why poor or unstable software is shipped.
1) Software follows hardware. People will not push as hard for
new hardware if there is no software to drive it, but once the
hardware is ready, WE NEED THAT SOFTWARE NOW.
A related issue is that in a hardware/software combined
project, the end date will often be fixed, and if the hardware
portion runs so late as to impact software testing, there will
be greater time pressure on the software team.
2) Companies know the real cost of shipping defective
hardware. You gotta recall the equipment, extract the
offending piece, replace it, or cut/add traces, etc. There are
real identifyable costs involved in shipping, reworking, spare
parts, etc. For software, the effects SEEM less costly. Mail
another diskette or tape.
3) There is a perception that everybody ships software before
its time. A company has to decide whether to also ship
prematurely, or take the time to do it right and suffer the
real/imagined opportunity cost of being the last one to
announce/deliver the product. The people who shipped the
shoddy software months ago may have had to ship several
updates, BUT THEY GOT THE SALE.
My own feelings are that the carefully planned and controlled project
should produce quality software just as quickly as a rush job could
produce shoddy software. The problem may be that upper management may
see a schedule that includes X months for planning, designing, and
specifications, X months for CODING, and X months for integration,
testing, etc, and wonder why it should take 3X months to finish the
project when all the "real work" only takes X.
Disclaimer: Anything attibuted to 'management' or 'company' in this
article does not necessarily reflect the opinion of the management of
Bunker Ramo or Olivetti.
In fact I know that my management takes software quality as seriously
as I do. My observations here are based on broad experience of over
ten years.
Joe Shapiro "My other car is a turbo...
Bunker Ramo Olivetti too."
{decvax,yale,philabs,oliveb}!bunker!shap
------------------------------
Date: Thu, 10 Mar 88 08:54:26 EST
From: mangoe@sdag.cs.umd.edu (Charles Wingate)
Subject: Why Software is Different
This "Why can't software people....?" exchange brings to mind a question:
How does software complexity really compare with hardware complexity? Has anyone done
a real comparison?
My gut feeling is that, when you eliminate the software part of the hardware (i.e.,
microcode or anything of that ilk) the hardware is going to tend to be much less complex.
I also suspect that it's more amenable to analysis. But these are just feelings. Any
ideas?
C. Wingate
------------------------------
Date: Thu, 10 Mar 88 16:54:57 PST
From: Eugene Miya <eugene@ames-nas.arpa>
Subject: Why Software is Different
I enjoyed Randy Neff's comments, I would only add one thing:
Hardware has a distinct engineering "advantage:" it either falls apart
(is subject to degradation) or has forces which succeed it. There are
some advantages toward a forced evolutionary process. Sure recognize
problems:
manufacturing or reproduction
typically prone to single point failure
etc.
Software on the other hand has given us the million line dusty deck.
(COBOL or FORTRAN take your pick). It's easily (too easily) reproduced,
What's scarier: the aging FAA computers or the bad software transported
to newer systems?
Evolution or revolution: did IBM get it right the first time?
Note that this version of evolution implies revisionist evolution
with jumps rather than gradual changes.
--eugene miya
NASA Ames
------------------------------
Date: Thu, 10 Mar 1988 20:44 EST
From: LIN@XX.LCS.MIT.EDU
Subject: Why Software is Different
It strikes me that another reason that hardware is more sophisticated
than software is that with hardware, production requires design
freezes to a much greater extent than software. Indeed, recall why
hardware is called hardware -- it is because physical things have to
be made. By contrast, software is much more akin to thought, and that
can be changed with much greater ease.
Result? It's easier to tinker with software, and thus the programmer
has much less incentive to think about the real gains from that last
change he's about to make.
------------------------------
Date: 9 Mar 88 13:32:42 GMT
From: mtune!mtgzz!mtgzy!mtuxo!homxb!houxs!beyer@rutgers.edu (J.BEYER)
Subject: Why Software is Different
When I used to be in hardware, the term 'maintenance' was used exclusively
for repairing something that broke. 'Enhancements' were not charged to a
maintenance budget, but to future engineering budget. In software, it seems
that Enhancements and continuing engineering are [I believe] mistakenly
charged to maintenance. This seems unfair.
------------------------------
Date: 12 Mar 88 02:54:49 GMT
From: trwrb!aero!venera.isi.edu!raveling@ucbvax.Berkeley.EDU (Paul Raveling)
Subject: Why Software is Different
>State-of-the-practice in Software:
>"THE PROGRAM IS PROVIDED "AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
>OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
>MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
>THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
>PROVE DEFECTIVE, YOU (AND NOT IBM OR AN AUTHORIZED PERSONAL COMPUTER DEALER)
>ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION"
>one paragraph from IBM program Licence Agreement (shrink wrap).
This is actually state of the art in litigation. You'll
find the same wording in limited warranty disclaimers for
lots of non-computing products because it's clearly defined
in law. You're right though that software goes MUCH farther
than anything else I can think of in invoking the law's
CYA shelters. I personally dislike these disclaimers intensely.
>All software is known by version number, both for bug fixes and enhancements:
>Turbo C 1.0, 1.1, 1.2, 1.5, etc. An Ada compiler 5.0, 5.1, 5.41, 5.5, etc.
... as is hardware. I've tailored software to suit boards
up to Revision M. If hardware makes it anywhere near that
level of revision it's almost certainly obsolete and will
be replaced soon by a new board at Rev A. I'd LOVE to be
able to use the same approach with lots of software.
Economics favors upgrading hardware as technology enables
producing a new product which can be manufactured for
less cost than an old product. The conventional "wisdom"
is that software should be reused to the hilt to hold down
costs. This works for some software, but causes BIG trouble
when reused components are a poor fit for new requirements.
Software management seems to be much more aware of the NIH
(Not Invented Here) syndrome than of the risk of the UWE
(Use Whatever Exists) syndrome.
Paul Raveling
Raveling@vaxa.isi.edu
------------------------------
Date: 12 Mar 88 04:12:47 GMT
From: trwrb!aero!venera.isi.edu!raveling@ucbvax.Berkeley.EDU (Paul Raveling)
Subject: Why Software is Different
>All three of these approaches in the software realm fall victim to the same
>concern: efficiency. This is partly a legacy of the 50s, when the self-taught
>programmers of the time were willing to do *anything* to squeeze out a few
>more cycles or a few words of memory. It was OK to violate any abstraction
>or to use any quirk of the system. ...
There's another side to this coin. What I see now is lots of
software being written without regard to performance.
Squeezing every ounce of speed and size out of the code made
sense when (for example) my time cost a princely $3.08/hr and
the machine cost $125/hr. But those old machines taught us
that efficient algorithms were a bigger win than efficient code.
They forced us to learn good habits in both algorithm design
and optimal coding. We had to do so much "optimal coding" that
it was quite painless to abandon it when machines grew
enough to eliminate the need.
Now I see lots of software being put together with minimum
implementation time as its sole goal. Yes, we have lots
of uncommented Lisp. The benchmarks show it runs about
3 times slower than C, which is about 3 times slower than
machine language. All that runs over an operating system,
Unix, which switches contexts an order of magnitude slower
than some other systems.
... and one of us (not me) wonders why his "high-tech"
workstation has worse response time than his PC at home.
Paul Raveling
Raveling@vaxa.isi.edu
------------------------------
Date: 9 Mar 88 17:05:36 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
Subject: Whistle-blowing and Responsibility
>How
>many incompetent people do you know who will admit to incompetence?
"Incompetence" has several possible meanings. It might, for instance,
mean that the individual is simply ignorant, perhaps even too ignorant
to realize it. Education, not punishment, is appropriate; if any punishment
is to be handed out, it should be to the managers that give ignorant persons
too much responsibility. Another sort of incompetent is one who knows
what should be done, but chooses to take shortcuts. Lots of punishment,
the more the better; there's ample legal precedent for this sort of thing.
Then there's the person with good intentions but botched results. Handslaps
and transfers to less responsible positions are the right answer.
>As an
>example, I could (but won't) cite a certain person who, having driven away
>one company's customers, later went on to a more responsible position with
>a much larger firm, where he today is happily convincing many people that
>his employer is completely incompetent, at least with the software he is
>involved in.
Why not name names? If you have facts to relate, then your moral duty is
to publicize them. Of course, this is in the same category as whistle
blowing, so I understand if you maybe want to line up another job first!
Perhaps ACM or IEEE could make themselves useful for a change and set up
something to support software whistleblowers...
stan shebs
shebs@cs.utah.edu
------------------------------
Date: 10 Mar 88 17:42:31 GMT
From: att-ih!pacbell!ptsfa!well!rmac@gargoyle.uchicago.edu (Robert J. McIlree)
Subject: Whistle-blowing and Responsibility
Uh, hold the phone here Stan. "Whistleblowing" pertains to those who
are committing crimes, like felonies, against their employers, the
government, etc. "Publicizing the facts", as you describe, would
probably result in one or more of the following (even if the
whistleblower had something else lined up):
1) To trumpet so-and-so as an incompetent software engineer
or manager would probably entail the release of the
company's proprietary information (i.e. the "facts, as you
put it). This leads to a lawsuit by company involved
against whistleblower, for revealing trade secrets and
violating the standard employment agreement most of us
sign when coming aboard.
2) In trumpeting so-snd-so as incompetent, so-and-so probably
has some very nice legal avenues to persue against the
"whistleblower" (I'd use a better term here, how about
"fink" or stool pigeon"?). Libel and slander come to
mind right away. This scenario can also be closely coupled
with scenario #1.
3) Finally, the "whistleblower/fink/stoolie" must become
public along with the target. Probably would get
publicized in the trades (after all, we are trying to
root out "problem" people, aren't we?) and prof. mags.
I, for one, would never hire the fink because, in the
absense of criminal activity as defined by law, he
could "blow his whistle" on me, for as small a reason
as disagreeing with my management or technical styles.
As you may suspect, the witch-hunts that start from
that type of approach would concievably leave us
all unemployed. Finks cannot be trusted.
As to your reference for ACM or IEEE to become policemen over our
profession, I for one do not pay dues to these organizations so
that the profession may be purged of your view of incompetent
individuals. Actually, our profession weeds out people who don't
belong in it pretty effectively anyway. People leave,
get fired, get promoted (as in the example), or start new careers.
So, equilibrium of "competent" folks is usally maintained accross the
board.
Finally, individuals compete with each other, companies do the same.
So if you were a competitor against the guy who screwed up, you'd
gloat. Because you'd get your stuff to market faster with higher
quality while he spins his (and the company's) wheels. See what I
mean?
Bob McIlree
{lll-crg,ihnp4,}!well!rmac
------------------------------
Date: 11 Mar 88 04:18:18 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
Subject: Whistleblowing and Responsibility
>[...] "Whistleblowing" pertains to those who
>are committing crimes, like felonies, against their employers, the
>government, etc.
I didn't realize that "whistleblowing" was so narrowly construed. What do
you call it if only civil statutes apply? Is a civil engineer who knowingly
specifies cheaper but unsafe materials in a building (which then collapses
as a result) only touchable via lawsuits? Is someone who publicizes the
engineer's misdeeds a nasty fink or a public hero? Would Roger Boisjoly (the
Challenger almost-whistleblower) have been a fink?
> 2) In trumpeting so-snd-so as incompetent, so-and-so probably
> has some very nice legal avenues to persue against the
> "whistleblower" (I'd use a better term here, how about
> "fink" or stool pidgeon"?). [...] Libel and slander
> come to mind right away.
If I recall my vague acquaintance with the law correctly, the truth is never
considered libelous. "X is incompetent" is not a provable statement. But
"X omitted range checks in critical code" or "Y released product Z 4.0 with
54 known bugs, one of which corrupts a PC's hard disk" are statements whose
truth can be tested objectively.
> I, for one, would never hire the fink because, in the
> absense of criminal activity as defined by law, he
> could "blow his whistle" on me, for as small a reason
> as disagreeing with my management or technical styles.
Even as a mere student in the ivory towers of academe, I hear all kinds
of stuff about who screwed up and why. Some of it is silly stuff about
management style, and some of it is more serious. I would probably prefer
to hire the "fink", at least if the "finking" was all factual, because I
would know that this person has enough of a sense of responsibility to stand
up to me, if I were to be tempted to do something wrong. The factualness is
important; witch-hunts come about when rumors are given more weight than
provable allegations.
>As to your reference for ACM or IEEE to become policemen over our
>profession, I for one do not pay dues to these organizations so
>that the profession may be purged of your view of incompetent
>individuals.
Doesn't have to be "my" views - there is plenty of "accepted wisdom"
in the field. ACM is actually not an appropriate organization anyhow,
since it is "scientific" rather than "professional" like IEEE. IEEE
could help implement licensing - I think some people have been working
on it (anybody know for sure?). Is there any reason why software engineers
should be exempt from the sort of licensing requirements found in other fields?
>Actually, our profession weeds out people who don't
>belong in it pretty effectively anyway. People leave,
>get fired, get promoted (as in the example), or start new careers.
"Getting promoted" is not my idea of effective weeding! And why would
programmers who do wrong things tend to start new careers more than those
who do right things? Come to think of it, why would they even get fired?
Based on my limited "real-world" experience (defense contractor, mostly),
there wasn't even any attempt to determine who (if anybody) was responsible
for mistakes! Given that, how could there have been any incentive to
write reliable software?
(Incidentally, my DoD work was for the air-launched cruise missile, and
although the standards for most of the software were pretty lax, the software
relating to nuclear safety was a different matter - there were elaborate
calculations on the probability of accidental detonation, although I don't
recall any sort of formal verification being done on the assembly (!) code
involved. Now you folks living near SAC bases can sleep easier tonight. :-) )
stan shebs
shebs@cs.utah.edu
------------------------------
Date: 12 Mar 88 10:41:38 GMT
From: trwrb!desint!geoff@ucbvax.Berkeley.EDU (Geoff Kuenning)
Subject: Whistleblowing and Responsibility
> Why not name names? If you have facts to relate, then your moral duty is
> to publicize them. Of course, this is in the same category as whistle
> blowing, so I understand if you maybe want to line up another job first!
> Perhaps ACM or IEEE could make themselves useful for a change and set up
> something to support software whistleblowers...
It's got nothing to do with job protection; in fact one could argue that
I have already cost the person in question one job. It's just that I don't
want to make enemies, and I know that he reads the net, though perhaps
not this group. It is quite possible to argue that my position is based
on opinions, not facts, software engineering being a somewhat ill-defined
discipline. I don't really see how writing that "Joe Blow of Fast
Computers, Inc. is an idiot who is damaging his company" is going to
help anyone. Certainly Fast Computers would qualify as an idiot company
if they fired Joe based on the word of an essentially anonymous net poster.
And I'd hate to get sued by Joe because he couldn't get a new job based
on my maligning him.
In any case, any competent interviewer would never hire this person for
the job he has. So why not just let Fast Computers dig their own grave?
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
------------------------------
End of Soft-Eng Digest
******************************
-------