[comp.software-eng] Unlimited software warranties

alex@am.sublink.org (Alex Martelli) (03/17/91)

I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature
frenzy" around, products are sold mostly on feechurs, secondly on
time-to-market, thirdly on price, and QUALITY just does not seem to be
on the list.  I am trying to redirect the discussion to c.s-e, because
it does not really seem peculiarly relevant to the world of 386 Unices:
I estimate that I spend between 25% and 40% of my time fighting with
bugs, BAD bugs, in compilers on all sorts of workstations, in debuggers,
in linkers, in system libraries, in RDBMS's, in utilities of all
descriptions... I'm TIRED! of this, but it does not seem to be getting
any better as time goes on: everything keeps getting faster and shinier
and richer - but quality stays low.  I do NOT need umpteen extensions to
language standards, which I will NOT use anyway since I want to write
PORTABLE software; I do NOT need compilers pushing the envelope in
hyperdimensional crosseverything optimization for a 7.2% speedup, when
the hardware itself is yearly doubling in performance; I do NOT need
linkers that will rearrange my code, inline called-once procedures,
and make coffee in the morning; I DO need BUG-FREE, *STABLE* software
tools, an ar that will not silently munge my archive if it's over 512
entries, a dbx that won't throw me into a wild goose chase by showing
the WRONG address for a symbol, a vi that won't dump core when i hit
^D to cancel autoindent and enter some text...

What can be done about it?  I believe there is a whole shift in emphasis
needed throughout the market: magazines and consulting organization 
should put benchmarks and feechur-lists into the second tier and start
ferreting around for BUGS; customers should insist on followup releases
to make software SOLID, rather than add chrome (such followups are 
today ignored as "just a bug-fix release"...); marketing teams should
figure out a way to sell based on QUALITY - "our product does NOT
dump core, it does NOT munge your data, it does NOT show wrong 
results"... CAN it really be so hard as all that???  In other markets,
after all, there ARE at least a portion of suppliers that do well by
selling high-quality, durable goods, where the buyer can rely on their
not breaking unexpectedly, rather than the "latest fads"; why, even in
our own 'hardware' field there are such markets.  Why not in sw too?

-- 
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

EGNILGES@pucc.Princeton.EDU (Ed Nilges) (03/19/91)

In article <1991Mar16.171033.380@am.sublink.org>, alex@am.sublink.org (Alex Martelli) writes:

>I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature
>frenzy" around, products are sold mostly on feechurs, secondly on
>time-to-market, thirdly on price, and QUALITY just does not seem to be
>on the list.  I am trying to redirect the discussion to c.s-e, because

Amen, Alex: but as to why quality is so little valued in software, look
at the recent discussion on counting "lines" of C code.  This discussion
took a badly-defined goal (counting lines of code in a free-form
language) and provided several solutions, none of which worked.  The
only solution that does work is to count statements according to the
strict Backus-Naur form definition of the language but the attitude
appears to be that this is "too complicated" and that pseudoclever
one-line sed or awk "tools" are more useful.

It's not just marketing that's at fault: it's an unholy alliance of
marketing, impatient for software that sells, and managers who have
forgotten that software is difficult and takes time.  It's also the
time-honored anticompetitive practises of the industry, in which the
big boys announce software, then run to the back room, chain the
programmers to their desks, and start cracking the whip.  Although
IBM pioneered this, Microsoft is now under FTC investigation for
exactly the same sort of practises (New York Times, 3/13/91, p. D1.)

>tools, an ar that will not silently munge my archive if it's over 512

If I had ten dollars for every time a programmer said, that number
will never exceed n, I'd be as rich as Billy Gates...the address
width of the IBM 360 is a good example.  It is easy to avoid magic
numbers and to use malloc in place of static allocation, but these
techniques don't seem to be taught.

>--
>Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
>Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
>Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
>Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

Ah, that explains it: the guy's from a foreign country.  Here in the
United States many of the concerns Alex raises are simply beyond the
ken of many programmers, since the educational system does such a
poor job in teaching students how to read/think/do math.

In the States we laugh at the Soviets and their lag in technology.
When I give seminars in C programming at a company in Chicago that
has hired Russian emigres, the performance of the emigres is MUCH
MUCH better than that of the US students.  This is because (1) these
students learned real math including the calculus in grade school and
(2) the very lack of personal computers taught these students how
to think critically about their code, as "desk-checking" is still
a prized skill in Soviet research institutions where Behemoth is
still the machine of choice.  It was a joy to teach these students
C based on Backus-Naur syntax and hand-execution in preference to
"put it on the machine and see if it breaks."

If programming is going to survive as a profession, programmers
need to design in quality even when management doesn't ask for it.
Why?  Because when the lawsuits begin when the software fails,
managers will point to the programmers as being at fault.  And,
like the guy peddling oatmeal on the boob tube says, writing
quality code is "the right thing to do."
+--------------------------------+ Edward G. Nilges
| Child support, tax-deductible  | Princeton University
| to payer AND receiver: an idea | Information Center
| whose time has come.           | Bitnet: EGNILGES@PUCC
+--------------------------------+ (609) 258-2985

chip@tct.uucp (Chip Salzenberg) (03/21/91)

According to alex@am.sublink.org (Alex Martelli):
>In other markets, after all, there ARE at least a portion of suppliers
>that do well by selling high-quality, durable goods, where the buyer can
>rely on their not breaking unexpectedly ...

A recent RISKS article (comp.risks) quotes an IBM paper to the effect
that 30% of the bugs in a widely-used OS did not show up until an
average of 5000 running years.  High-quality software is difficult.

Given that bugs will constantly be discovered, I think the best we can
reasonably ask is a serious effort to fix bugs NOW instead of saying,
"Wait until the next release."

Of all the vendors I've worked with, the one that comes closest to the
ideal in this respect is (gasp) IBM.

We just got an RS/6000, and each and every bug that I've reported has
been dealt with.  Some are still pending (gotta love bureaucracy), but
two bugs were solved with fixes sent by overnight express.  More
significantly for this discussion, they have never said, "Fixed in the
next release," unless they said in the same breath, "and let me send
that to you now."

Whatever you want to say about IBM, they take support seriously.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
   "All this is conjecture of course, since I *only* post in the nude.
    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre

alan@tivoli.UUCP (Alan R. Weiss) (03/22/91)

In article <12600@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes:

[much good flaming deleted ... lots of stuff to chew on].

>If programming is going to survive as a profession, programmers
>need to design in quality even when management doesn't ask for it.
>Why?  Because when the lawsuits begin when the software fails,
>managers will point to the programmers as being at fault.  And,
>like the guy peddling oatmeal on the boob tube says, writing
>quality code is "the right thing to do."
>+--------------------------------+ Edward G. Nilges
>| Child support, tax-deductible  | Princeton University
>| to payer AND receiver: an idea | Information Center
>| whose time has come.           | Bitnet: EGNILGES@PUCC
>+--------------------------------+ (609) 258-2985

This actually raises a different but related question:  when the lawsuits
begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
"legally liable?"  Possible culprits:

	1.  Marketing people
	2.  Senior management (i.e. officers of the firm)
	3.  Development management
	4.  Developers/programmers
	5.  Quality Assurance management
	6.  QA engineers
	7.  The customer

In keeping with the spirit of Usenet and news, I'll make my choices
after I hear *your* input  :-)  OK, I'll give in a little:  it sure
as hell isn't the customer's fault (i.e. "the market made me do it").

_______________________________________________________________________
Alan R. Weiss                           TIVOLI Systems, Inc.
E-mail: alan@tivoli.com                 6034 West Courtyard Drive,
E-mail: alan@whitney.tivoli.com	        Suite 210
Voice : (512) 794-9070                  Austin, Texas USA  78730
Fax   : (512) 794-0623   "No business would dare say these things!"
_______________________________________________________________________

jerry@TALOS.UUCP (Jerry Gitomer) (03/22/91)

alan@tivoli.UUCP (Alan R. Weiss) writes:

|In article <12600@pucc.Princeton.EDU| EGNILGES@pucc.Princeton.EDU writes:

|[much good flaming deleted ... lots of stuff to chew on].

||If programming is going to survive as a profession, programmers
||need to design in quality even when management doesn't ask for it.
||Why?  Because when the lawsuits begin when the software fails,
||managers will point to the programmers as being at fault.  And,
||like the guy peddling oatmeal on the boob tube says, writing
||quality code is "the right thing to do."
||+--------------------------------+ Edward G. Nilges

|This actually raises a different but related question:  when the lawsuits
|begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
|"legally liable?"  Possible culprits:

|Alan R. Weiss                           TIVOLI Systems, Inc.

	Whoever the judges and juries elect to find at fault!  Like
	marketing issues this has nothing to do with logic, but is a
	matter of perception.

			Jerry

--
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell (703)683-9090      (UUCP:  ...{uupsi,vrdxhq}!pbs!npri6!jerry

jls@rutabaga.Rational.COM (Jim Showalter) (03/24/91)

>This actually raises a different but related question:  when the lawsuits
>begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
>"legally liable?"

The corporate entity, as is true in any other product liability case.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

thayne@unislc.uucp (Thayne Forbes) (03/26/91)

alex@am.sublink.org (Alex Martelli) writes:
>I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature
>frenzy" around, products are sold mostly on feechurs, secondly on
>time-to-market, thirdly on price, and QUALITY just does not seem to be
>on the list.  
I don't profess to be any kind of authority on this, because my experience
has been somewhat under protest.  However, allow me to espouse a trite
philosophy that I believe is original. (If not, someone point me to a
reference).  That is:  Software evolves into the product that is being
tested in QA.  I was stuck at a vendor sight for several months testing a
product that 'they' thought was ready to go any day now.  I consistently
found bugs that they had never seen (4-5 a day).  And the telling response
was "Well why would anyone want to do that"

>What can be done about it?  I believe there is a whole shift in emphasis
>needed throughout the market: magazines and consulting organization 
>should put benchmarks and feechur-lists into the second tier and start
>ferreting around for BUGS; 

That was part of the problem with this product.  Our customer (DoD) had
already decided what the features were going to be, and our vendor had
the attitude that all they had to do was meet that criterion.  And meet
it on schedule.  And without spending so much time that they lost all
their profit on our prearranged price/unit.  Do you see how quality got
to be fourth on their list??

Thayne Forbes  (Unisys, Salt Lake City, Ut)
thayne@unislc.UUCP || {att, hpda, sun, uplherc}!unislc!thayne || (801) 594-4826
-- 

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# The opinions expressed above are my wife's, but she said I could use them. 

alan@tivoli.UUCP (Alan R. Weiss) (03/26/91)

In article <jls.669769186@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>This actually raises a different but related question:  when the lawsuits
>>begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
>>"legally liable?"
>

Hiya, Jim.  You kind of begged the question, but your point is valid.
However, in many negligence cases the officers of the company are also
held personally liable (the unfortunately classic example is the Union Carbide
Bhopal disaster)..

Anyway, back to my main concern:  who is at fault?

 

_______________________________________________________________________
Alan R. Weiss                           TIVOLI Systems, Inc.
E-mail: alan@tivoli.com                 6034 West Courtyard Drive,
E-mail: alan@whitney.tivoli.com	        Suite 210
Voice : (512) 794-9070                  Austin, Texas USA  78730
Fax   : (512) 794-0623  ObDisclaimer:  I speak for myself, not my company
_______________________________________________________________________

kambic@iccgcc.decnet.ab.com (03/26/91)

In article <497@tivoli.UUCP>, alan@tivoli.UUCP (Alan R. Weiss) writes:
> In article <12600@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes:
> 
> [much good flaming deleted ... lots of stuff to chew on].
> 
> This actually raises a different but related question:  when the lawsuits
> begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
> "legally liable?"  Possible culprits:
> 
> 	1.  Marketing people
> 	2.  Senior management (i.e. officers of the firm)
> 	3.  Development management
> 	4.  Developers/programmers
> 	5.  Quality Assurance management
> 	6.  QA engineers
> 	7.  The customer
> 
IMHO I believe that there is something called "strict liability" coming into
play here, like if you did the code, you did it, and you had better be able to
say why and show that it was the best possible code that could be done that
way.  Then find a lawyer.   Preferably a software lawyer.  How about a legal
knowledge assistant?

GXKambic
standard disclaimer

egnilges@phoenix.Princeton.EDU (Ed Nilges) (03/26/91)

In article <1991Mar25.171643.3461@unislc.uucp> thayne@unislc.uucp (Thayne Forbes) writes:
>
>That was part of the problem with this product.  Our customer (DoD) had
>already decided what the features were going to be, and our vendor had
>the attitude that all they had to do was meet that criterion.  And meet
>it on schedule.  And without spending so much time that they lost all
>their profit on our prearranged price/unit.  Do you see how quality got
>to be fourth on their list??
>
>Thayne Forbes  (Unisys, Salt Lake City, Ut)

Thayne, this illustrates my point that software designers have a dual
responsibility.  They are of course responsible to management and they
must in some sense do what they are told.  But they are also responsible
to themselves as a profession, if only to avoid liability when
mission-critical software breaks.

In the New York Times for March 24th, a group from your own company
(UniSys) comes in for criticism because of the nonworking status of 
a new weather radar system.  The article, on page a1 and with no
byline, states that a consultant from the Patents and Trade Marks
office (Thomas Giammo) claims that "Air Force testers had given
Unisys's computer programming office its lowest rating."  The
article did NOT make clear that a company such as Unisys has many
computer programming "offices": but imagine agreeing to management
demands for down-and-dirty, bug-ridden products and several weeks
later opening the paper to read that the quality of the system you
worked-on has been decried to the extent that the Unisys system
was decried.  Or worse, getting a letter from a lawyer accusing YOU
of poor practices after you fought for quality and lost.

jls@rutabaga.Rational.COM (Jim Showalter) (03/27/91)

>In article <jls.669769186@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>>This actually raises a different but related question:  when the lawsuits
>>>begin, WHO IS AT FAULT?  Can we distiguish between "at fault" and
>>>"legally liable?"

I didn't actually write that. I responded to it. Sigh: aren't BBS's fun?
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

alan@tivoli.UUCP (Alan R. Weiss) (03/29/91)

In article <1991Mar25.171643.3461@unislc.uucp> thayne@unislc.uucp (Thayne Forbes) writes:
>alex@am.sublink.org (Alex Martelli) writes:
>>I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature
>>frenzy" around, products are sold mostly on feechurs, secondly on
>>time-to-market, thirdly on price, and QUALITY just does not seem to be
>>on the list.  
>I don't profess to be any kind of authority on this, because my experience
>has been somewhat under protest.  However, allow me to espouse a trite
>philosophy that I believe is original. (If not, someone point me to a
>reference).  That is:  Software evolves into the product that is being
>tested in QA.  I was stuck at a vendor sight for several months testing a
>product that 'they' thought was ready to go any day now.  I consistently
>found bugs that they had never seen (4-5 a day).  And the telling response
>was "Well why would anyone want to do that"


Thayne:

Does Unisys still have a Product Assurance and Support (PA&S) function?
Long ago, I worked in PA&S at Burroughs (later Unisys)-Camarillo plant.
Or, has Unisys gutted THAT like they've destroyed most things?

(For those of you who are hard at work at a Unisys facility, my
sincere apologies for sounding so negative.  But I remember when the
Burroughs name MEANT something, dammit, and when quality really
mattered.  Yeah, the engineers bitched about Phase Review, and
Corporate Systems Management was something to be a little feared.
But schedules were met, and quality was good, and profits were
at least a *little* bit present.  Then the political hacks took over:
Blumenthal especially.... Again, nothing personal).


_______________________________________________________________________
Alan R. Weiss                           TIVOLI Systems, Inc.
E-mail: alan@tivoli.com                 6034 West Courtyard Drive,
E-mail: alan@whitney.tivoli.com         Suite 210
Voice : (512) 794-9070                  Austin, Texas USA  78730
Fax   : (512) 794-0623     "I speak only for myself, not for TIVOLI"
_______________________________________________________________________