Unlimited software warranties

[Dick Dunn]

(Note in passing:  I'm not commenting on a lot of what John wrote because
I think he's pretty close to the target.  There are a few things I'd like
to latch on to for some quick comments.)

jgd at Dixie.Com (John G. DeArmond) writes:

>...And considering that the price of cars has not kept up with the cost of
> goods sold while software prices have been on a steady increase over
> the last couple of years, arguing the cost of supporting a good warranty 
> sounds even sillier.

I think the "cost per pound" of software has not gone up that much!  I'm
serious--I think that if you check $/Mb, you'll find it's level or even
down.  (The issue of whether you want all those extra Mb in the package is
a separate one--that's not my point here.:-)

> The premise that a vendor must charge large bucks to cover expenses before
> the product obsoletes is equally empty.  The lifetime of most major
> successful software is measured in fractions of a decade.  Unix - almost 20 
> years...

Hold on.  That's wrong.  UNIX (the name) may be 20 years old.  UNIX (the
software being sold today as Sys V.3.2) is mostly fairly new.  I would bet
that less than 5% of today's kernel is more than 10 years old, let alone
20.  Both of us may find it lamentable that the code is in such a state of
flux, but that doesn't change the fact that it is.

If you'd seen the figures coming out as V.4 emerged, you would have been
amazed at the amount of new/changed code with each delivery.  We're talking
time frame of months and change/new amounts of 10^5-10^6 lines.  That costs
money.  Again, you can argue whether it's money well-spent, and/or whether
you really want to pay for it, but don't think the OS is a cash cow sitting
in the corner that you just milk whenever you want money.

> >Software is actually worse, because of compatibility:  We're carrying every
> >tailfin and chrome strip for the last twelve years.
> 
> Actually, in many cases, its the useless chrome and tailfins as excess
> baggage that's the problem...
> ...What we want are good, reliable hotrods.  Fast, efficient
> and simple.
...and somewhat later on...
> ...The software
> business is now about where the automobile business was in 1968.  

Actually, John, in another place you used the Toyota analogy, which I like
a little better than hotrod, but be that as it may.  This brings me back to
my original ranting.  Sure, I want a Toyota-like OS...but I'm atypical.
And I don't believe 1968; I say the OS market stands today about where
cars did in '59.
    In '59, people wanted big tail fins, V8's, and lots of chrome.  They
    didn't care about weight or mileage.  Gas was cheap and plentiful.
    They didn't even mind that those land yachts, artificially lengthened
    by a couple feet, were hard to park.  I doubt you could have given
    away a Toyota Corolla back then.
				---
    In '91, people want a big OS with all the features and a chrome-plated
    bas-relief GUI at any cost.  They don't care if it wastes memory or
    it's slow--memory is cheap and CPUs keep getting faster.  I think
    Peter's idea of "UNIX Classic" is neat, but I doubt you could give it
    away to more than a handful of people.

> I'm not sure I agree that feature wars are a major component in software
> cost.  I'd more likely agree that it is a source of many bugs...

The latter statement is obvious; I don't follow the former.  Features are
an obvious source of bugs--why?  Because they involve adding code and
adding interactions among existing pieces of code.  That's why they cost--
adding code costs money (and adding un-needed code wastes money.)

>...In any
> event, the solution from the vendor's perspective involves strong 
> participation in standards activities and selectively just saying NO
> to creeping featurism.  Unnecessary embelishments on established standards
> should receive the same level of distain as would a "new and improved" 
> bolt thread standard.

Alas, software standards activities are one of the biggest sources of
rampant, gratuitous feature frenzy.  Have a look at the "international-
ization" goo that wants every program to be at least a page of code, and
which has propagated baroque national-collating-sequence requirements into
programs that heretofore had nothing to do with natural language issues.
(This came about from the idiotic prejudice that ASCII somehow represents
a parochial US-English collating sequence.)  Notice that we're going to get
to deal with ISO OSI in the lower network layers--not because TCP/IP had
problems there, but precisely because TCP/IP was an accepted, widely-used,
successful standard!  (It was used too heavily in the US to be accepted:-)
Look at the trigraph wart in standard C--something that nobody really
wanted and that doesn't solve the problem anyway.  Try to sort through the
chaos of how ttys are supposed to work.  I could go on for megabytes.

The standards process *shouldn't* work this way--but it does.  It's broken
worse than what individual software vendors are doing.
-- 
Dick Dunn     rcd at ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...Relax...don't worry...have a homebrew.