Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Plea for help: The detriment of using Microsoft products



On Tue, 16 May 2000, Mike Bilow wrote:

> Date: Tue, 16 May 2000 17:37:55 -0400 (EDT)
> From: Mike Bilow <mikebw at colossus.bilow.com>
> To: Jeffry Smith <smith at missioncriticallinux.com>
> Cc: Kevin D. Clark <kclark at cabletron.com>, GNHLUG <gnhlug at zk3.dec.com>,
     BLU Users' Group <discuss at Blu.Org>
> Subject: Re: Plea for help: The detriment of using Microsoft products 
> 
> Given that I criticized Minasi rather severely for his horrendously flawed
> "Inside OS/2" series of books, I find his emergence as a quality expert
> rather ironic, to say the least.
> 
> I do not believe there are any CMM5 operations in India.  There may well
> be places that claim to be at CMM5, but this is not like ISO9000 where the
> main qualification is to write a big enough check.  I am quite certain
> that the US DoD does not contract out critical software to India.

For a list as of 4 May 2000, see: 
http://www.sei.cmu.edu/cmm/high-maturity/HighMatOrgs.html
SEI, despite founding and support from DoD, is not DoD unique.
> 
> The fundamental problem with CMM5 is that its total focus is on task
> completion.  When you build an aircraft, no one expects that major
> features will be added periodically.  No one at Boeing marketing sits
> around at meetings and proposes, "Hey, why not strap a couple of extra
> engines onto each model, so that customers with the two-engine model can
> upgrade to four engines and customers with the four-engine model can
> upgrade to six engines?"  Yet this is common practice in the software
> industry.  When you are doing the software for something like the Space
> Shuttle or the firmware for a Boeing airliner, the project gets completed
> and rolled out in a state that remains largely stable forever, and this is
> what makes CMM5 possible in such environments.

Because they know that adding 2 more engines will actaully HARM
performance!  Yes, it's common practice in the SW industry.
And, routinely, we see performance suffer.  Because no-one
goes back and points that out to the customer.  For Boeing,
they have to point it out.  Add an extra 2 engines to a 767,
and the plane will crash.  And Boeing will get sued to
oblivion.  It's called LIABILITY!  Something the SW industry
routinely denies having.  So, Boeing tell you (politely) you're out of
your mind.  And the airlines listen.  Why?  Because Boeing has the 
experts, and if they could, they would sell it.  Note, However, the 
interior of every Boeing jet is customized to the airline/customer.
The avionics are routinely upgraded (being truly plug & play,
interfaces specified, then design device that meets the interface).
Engines are routinely upgraded (because the new engines are form &
function replacements, not custom built).  In fact, except for the
framework, the whole jet can be replaced.  Even the wings (admittedly,
a huge job, but it has been done).  Why, because it's
designed right to start with. 


 > 
> Where the life span of a software product may only be a few months, it is
> impossible to justify the kind of effort required to achieve CMM5-level
> quality control.  By the time such software passed quality control, it
> would be obsolete.  Further, the human costs are not comparable: no matter
> what security vulnerabilities are seen in Microsoft Outlook, the
> consequences of total collapse of the system do not involve fire,
> explosion, or people being hurled out of the sky from thousands of feet.

No, it costs businesses 2 days of work, millions of dollars.  So,
because no one was killed, MS shouldn't be held liable?  
BTW:  In terms of life span:  Linux is based on Unix, which is, what,
30 years old?  Sure, the product may be upgraded, but the functions
don't change that much.  It comes down to designing it RIGHT.
Building in modules.  Defining interfaces.  Regression testing.  It
can be done.

> 
> My expectations are more realistic.  I do not expect Microsoft to bring
> their mail software to CMM5 because, quite honestly, I do not think it is
> worth paying for that.  On the other hand, I would like to see Microsoft
> stop obviously stupid things, such as leaving security off by default.
> 
> -- Mike

You know, Detroit made the same arguments about Deming and his TQM.
"It costs too much to build in quality."  "It takes too long to do it
right."  "It will be obsolete before it rolls out the door."  Then the
Japanese came along.  Who listened to Deming.  Who pointed out that:
"If there's time to do it over, there's time to do it right."  "Every
problem found in design is 1/100 the repair cost of a problem found in
production."  "Every penny of scrap is a penny of lost profit."  
Guess who won (hint:  the other guys scrambled for over a decade to
get back on the train)?

I agree with Minasi.  The main reason they get away with it is people
let them.  

jeff
------------------------------------------------------------------------
Jeffry Smith      Technical Sales Consultant     Mission Critical Linux
smith at missioncriticallinux.com phone:978.446.9166,x271 fax:978.446.9470
------------------------------------------------------------------------
Thought for today:  Between infinite and short there is a big difference.
		-- G.H. Gonnet


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org