Plea for help: The detriment of using Microsoft products

[Jeffry Smith]

On Tue, 16 May 2000, Kevin D. Clark wrote:

> Date: Tue, 16 May 2000 11:16:27 -0400 (EDT)
> From: Kevin D. Clark <kclark at cabletron.com>
> To: Jeffry Smith <smith at missioncriticallinux.com>
> Cc: GNHLUG <gnhlug at zk3.dec.com>, BLU Users' Group <discuss at blu.org>
> Subject: Re: Plea for help: The detriment of using Microsoft products 
> 
> 
> Jeffry Smith writes:
> 
> > Boeing
> > jets are extremely complex, requiring hundreds of thousands, if not
> > millions of parts, each of which must do its job correctly.  The
> > odds are that there are flaws in the jets.  Yet, as recent actions
> > involving the Boeing 737 show, Boeing is held legally and financially
> > liable for the performance of their airplanes.  The software industry  
> > argues that, with products of similar complexity, they CANNOT be held
> > liable. Why?  
> 
> Computer science is still a maturing field, and the technology
> involved changes so rapidly that it's to stay on top of everything.
> Combine this with a market that seems to favor "more features" and
> "speed to the market" over "general stability", and, well, look
> around, that's the situation we find ourselves in.
> 
Look at the book I recommended. One thing he points to is CMU's
Software Engineering institute, and their Capability Maturity Model.
The interesting thing is that their recommendations amount to TQM,
straight from the hardware world (i.e  do you have a process, do you
measure your process, do you have goals, etc). This is something I
keep pointing out.  Yes, CS is a maturing field.  So was Aerospace in
the early 20th century.  So, they used Mechanical Engineering,
Chemical Engineering, Naval Engineering, etc, as a basis.  Extended it
into the air and later the space world.  You build on the processes of
others.  Why do we favor more features?  Because no one in their
reviews tests code, because people accept that buggy code is OK.  In
terms of speed to market, Minasi points out that CMM level 5 companies
(most in India, by the way, despite SEI being sponsored by the US DoD.
anyone remember the 70's & US & Japanese auto makers), actually
deliver code quicker.  Why?  Because the quality is built in.  They
catch the problems earlier by doing the design right the first time. 

> I write code for a living, and every day I strive to juggle the tasks
> of implementing the features that the customer wants and making sure
> that there are no bugs in the code.  This is no easy task.  I enjoy
> the challenge though, so I keep on slugging away.
> 
> I love open-source software because it facilitates the whole idea of
> peer-review, which I think is a critical part of good software
> design.  Every once in a while I find a bug in an open-source
> project's code-base, and generally I can just go to the source, figure
> out the problem, fix it, and send a patch to the packages
> maintainers.  I find this to be very empowering and I think that it
> leads to better software.
Yep, peer review of design, code, testing,etc.  Sounds a lot like HW
engineering.
> 
> I don't think that a lot of shops out there do a lot of peer-review,
> and I believe that this tends to produce lower-quality software.  I'd
> bet a million dollars that Boeing's engineers do a lot of peer-review
> when designing their airplanes.  Because failure is not an option...
Bingo.  Failure is NOT an option, Boeing's a** is on the line.  They
CANNOT waive liability.  Unlike the standard SW company.
 
> Writing good software is *hard*.
No argument.  That's not an excuse not to do it, though.
> 
> Want to see an example of a software group that produces solid code?
> Read this article:
> 
>    http://www.fastcompany.com/online/06/writestuff.html
> 
> Now, to be fair, these people have a rather large budget and their
> customer isn't really demanding a lot of new features.  But the
> article gives a flavor for how hard it is to get things right.
Minasi talks about the Shuttle SW.  Yep, they had a large budget.
They also only had one customer.  How many customers does MS have to
spread the cost of MS Office development over?
Also, in reading the article, note the emphasis at finding errors (not
bugs, errors, that's what they are) at all levels. Regression testing
of all code (we sort of have something like it in Linux, but we could
use various companies to do more of it.  Estabilish standard tests for
each system call, then test each new version.  Note that the LSB test
suite guys are developing this.)


> 
> Now, all of this said, the path of destruction left over by the recent
> worm only further confirms my belief that something is seriously wrong
> over in Microsoft's software shop.  I can't even believe that the
> (mis-)features in Outlook that allowed the worm to work in the first
> place ever made it through a design review.  What were they thinking?
> 
That if something goes wrong, oh well, it's someone else's problem.
We've waived all liability.  Tough luck, we'll fix it in the next
upgrade.

> (contrast the mindset of the people who designed these "features" into
> Outlook with the people at Sun who designed the Java applet security
> model -- in one case we have responsible engineering, and in the other
> case we have something that gives me a headache just thinking about it)
> 
> --kevin
> 
Note that Gnumeric (open source) has VB built in for Excel
compatibility.  SANDBOXED VB.  What MS should have done to begin with.
A bunch of hackers doing it for nothing do it right, MS, for all their
money, doesn't (I refuse to say can't.  They chose not to, just like
Ford chose not to fix the Pinto.  Their choice, now they should live
with the consequences.)

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).