Plea for help: The detriment of using Microsoft products

[ddm at mclinux.com (Derek Martin)]

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

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

Tort law is tort law.  What's the difference?  If Microsoft's products (or
any other software company's, for that matter) cause you to lose
time/money/resources, why can't they be held accountable?  It just doesn't
make any sense.

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

Sure, but it's up to your management (project, product, whatever) to make
sure that when it all ships out the door, it doesn't screw someone over.
Microsoft refuses this responsibility (as do others). [I don't want to be
viewed as picking on only Microsoft -- they're the worst, but they're not
alone. I'd hate to be pegged as a Microsoft basher...]

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

BINGO.  

The problem on the whole with commercial software, as I see it, is they're
under pressure to get software out the door as quickly as possible,
because software sitting in revison control repositories generates no
revenue.  

The side effect this produces is that QA groups do as little alpha and
beta testing as they think they can get away with.  No one IS going back
over the code with a fine-toothed comb, so to speak.

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

Right on the mark.

> Writing good software is *hard*.

Yes, but it isn't impossible.  And it certainly isn't as hard as Microsoft
makes it look.

> Want to see an example of a software group that produces solid code?
> Read this article:
> 
>    http://www.fastcompany.com/online/06/writestuff.html

Soon as I get a second, I will!

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

I think it's fair to say that Microsoft's customers probably aren't really
demanding huge amounts of new features either.  I think that's a line they
give to cover their ass.  But the fact is they have a difficult time
selling updates if they can't say you're getting xyz new features for your
$99 or whatever.  So they add stuff, which may or may not work.  And may
or may not cause other problems.

> 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?

Exactly.

-- 
Derek Martin
System Administrator
Mission Critical Linux
martin at MissionCriticalLinux.com 

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