a better analogy for the warranty discussion?

[John G. DeArmond]

rcd at ico.isc.com (Dick Dunn) writes:

>I think some of the discussion about quality and (unlimited) warranties is
>getting sidetracked by the automobile analogy.  I understand the value of
>an analogy, since we're really aiming at how the software world could be
>re-shaped in some other mold, but I think we need a closer analogy.  John
>DeArmond got more out of the analogy than I would have expected--but his
>arguments fall short in a couple of places, as do the arguments of the
>folks on the other side.  

Actually, the more I think about my analogy, the more parallels I see
between software and automobiles.

>Another problem is that cars are bought and sold; software is licensed.

Let's get one thing out of the way up front.  With the rare exception of
vendors who sign an a priori contract with a buyer, the only licensing
that occures with shrink-wrapped software is in the minds of the vendors.
Legally the SALE of shrink-wrapped software falls under the purview of
the UCC which governs all sales absent a contract.

The trivial argument to those who dont' believe this is that if the vendor
has the right to proffer a unilaterial contract and make it stick, I have
the right to unilaterally modify that contract to my liking before 
initiating the acceptance act (bursting the shrink-wrap in most cases).
I, of course, delete any as-is warranty dislaimers, write in my own
satisfaction-guaranteed warranty :-), delete any single machine
clauses and change the state of juristdiction to Georgia.  Where we
really end up after this flight of fantacy is back under UCC.

So we buy a car and we buy software.  The analogy holds.

>One problem with cars is that they're physical objects which wear out in a
>very real, direct, observable sense.  (A couple of people have pointed out
>that software also "wears out"--but in such a different sense that although
>I agree with the point, I don't think it supports the analogy.)

That is ultimately beside the point for most instances.  The analogy is 
that for most people, they want a new product (and the vendor wants them
to buy a new product) long before the old one is obsolete.  I happily
drive my 15 year old Datsun Z and I happily edit under DOS using my 
almost 15 year old WordStar.  Both Detriot and the software guys would
have liked me to have upgraded years ago.

>You might use books rather than cars to answer these two analogy
>breakdowns.  The point of purchasing a book is usually for the contents
>much more than for the embodiment.  You are licensing a copy of a written
>work.  And while books do wear out, that's relatively rare.  The
>information content remains.  

I don't totally agree with the commercial analogy to a book but I'd like to 
point out that technical books DO obsolete about as fast as software.  I just
bought the second edition of Comer (TCP/IP) for that very reason.  I bought
it for the same reason that I upgrade some software, namely, to get new
features - in this case, new protocol information that has evolved since
the last writing.

>Books also allow us to carry the red herring
>argument about software, that "every defect was there from the start".  If
>your encyclopedia says that the atomic number of Fe is 37, it's wrong; it's
>a defect (a "bug") and was there from the start.  You have to be a little
>careful about the scale between books and software; for example, the K&R
>white book is about the equivalent of half a meg of source code.  Also,
>prose is more forgiving--an error in number, tense, or mood of a verb
>seldom produces a catastrophic misunderstanding.  Still, books can be a
>useful analogy to software when more tangible mechanical objects don't
>compare.

Actually, you've made your analogy better with this paragraph.  The printed
text is exactly like software executables.  The "source code" in this case
is the typesetting text with all the formatting commands.  Troff source,
for example.

Secondly, errors in context have almost the same result.  True, a verb may
not affect the meaning of a sentence anymore than an extra character on 
a data entry screen won't affect its functionality.  But if Comer told me
that Telnet used port 24 instead of 23, that would be as catastrophic
as an inverted branch decision in software.

>One of the major differences between software and cars is that there's a
>very different class of interoperability.  I can drive a Toyota or a
>Cadillac on the same road--if this were the world of software I'd only be
>able to drive on Toyota roads, and if they didn't go where I wanted to go,
>I'd have to buy a different kind of car!  

What you're actually pointing out is a failure in the software industry
in the area of binary compatability.  I suspect that one day soon we'll
get there if the software companies will learn enough to have an SAE of
the software world.  Silicon is getting fast enough that the binary 
code one day soon will be for a virtual machine whose instructions are
executed in microcode by a wide variety of divergent physical architectures.
That this virutal machine might end up being a 386 makes me wanna gag but
I digress :-)


What this discussion is converging into is the idea that software is 
no different than any other merchandised product such as automobiles
or books.  The failing of the industry is that it has failed to adopt
the lessons of merchandising learned long ago in other segments of
the economy.

John

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it