Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!grebyn!escom!al
From: al@escom.com (Al Donaldson)
Newsgroups: comp.misc
Subject: Re: A tirade about inefficient software & systems
Message-ID: <608@escom.com>
Date: 1 Nov 90 17:14:24 GMT
References: <9886@milton.u.washington.edu> <1990Nov1.002513.8984@ico.isc.com>
Organization: ESCOM Corp., Oakton, VA
Lines: 58

Dick,

Excellent description of the state of the market.

> Start with a system X that's got n bullet-list...
>
People make decisions based on bullet lists.  OK, you expect it when
Fred Flintstone goes to the store to buy a dessert topping (Hmmmm.
this one is a dessert topping AND a floor polish...) but you somehow
expect more when large corporations make decisions.  But they're
the worst.

> Vendors make bigger, slower systems because that's what happens when you
> keep adding features.  People buy features.  In the realm of software,
> very few people buy performance.
>
Bloat isn't just confined to software; our hardware cousins are just as bad.
I once worked on a secure LAN project where our goals were to keep it
simple and fast, in addition to secure.  But our hardware designers would
stay up at night trying to find interface chips that had extra FEATURES on
them so that they could add extra logic to the board to use those features
which would require an n+1 layer board instead of an n layer board.
Well, someone might need to use that feature sometime or other...

> Look at UNIX as it was a decade ago.  UNIX was made up of
> a small, elegant kernel, plus a large collection of small applications,
> each of which did a few things very well.  You put together tools from
> this neat toolkit, and they just worked.
>
For a more current example, look at MINIX for the PC (AT, etc..) family.
Andy Tanenbaum designed it to be small and simple, but there have been 
calls to rebuild it to handle large-model applications (larger than 64K+64K).
Why?  So people can run G-this and X-that, applications that never were
dreamed of for Version 7.

> They want it all fitted out for them; if they want four, they're
> not willing to put two and two together.  In the harshest way of stating
> it, they're buying the software bloat so they don't have to think instead.
>
I once worked on a network interface for an unnamed government organization
where the spec required an incoming packet to be processed and transmitted 
in 21 millisecs.  Hard requirement, they said.  Plus you had to have a 50% 
reserve capacity built in, so that meant doing the job in 14 msec.  Why?  
Well, that was the maximum clock rate on the UARTs (224Kbps), and their 
hardware didn't support queueing.  It never occured to these people to break 
the line up into four 56Kbps lines, which would have been duck soup from 
a performance point of view.  So the government and all their hired guns 
(Mitre and Aerospace) and the contractor and subcontractors all spun their 
wheels for a year trying to figure out if a certain CPU could do the job 
(with a 50% safety margin!!) instead of just building the damn system and 
buying three extra cables if necessary.  So with all the studies and 
alternate proposals that were done, the actual cost for the contractor was 
something like $20 million instead of the bid price of $5 million.  And that 
didn't count all the green stamps that the government and its hired guns 
spent looking over our shoulder.  Well, not MY shoulder.  I finally had 
enough and left.  

Al