Plea for help: The detriment of using Microsoft products

[smith at missioncriticallinux.com (Jeffry Smith)]

On Tue, 16 May 2000, John Chambers wrote:

> 
> Jeffry Smith wrote:
> 	 On Tue, 16 May 2000, Kevin D. Clark wrote:
> 	 ...
> 	 > 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.
> 
> In my experience, code reviews are very common.  But I've yet to  see
> such  reviews catch even a single bug.  The current "standard" in the
> commercial software biz is so weak that it only qualifies as a parody
> of a true review process.
> 
> When it was my code being reviewed, I have never seen  anyone  ask  a
> question  that  I  hadn't already asked myself.  Now, you might think
> that this just indicates what a competent  programmer  I  am,  and  I
> wouldn't  want  to  disabuse  you of that idea.  But I think the real
> explanation is indicated by the changes that do come out of  reviews.
> I'm  thinking  of  the  hour-long debates over such things as whether
> open braces should be on a separate line, or should be at the end  of
> the  if/while/for expression.  This is the sort of "software quality"
> problem that current reviews are designed to handle.
Well, in looking at the fastcompany web page you presented, their #3
item was the important one:  Keep track of EVERY CHANGE, including why
the change, and what the result was.  Code Reviews needs to include
(and from the discussion above yours didn't):
1.  Comparison with the desired functionality (does the design
accomplish the desired task)
2.  Logical analysis of the design (not the code, the design.  This
is the "do we cover all possible conditions" check.)
3.  Comparison with past known working designs
4.  Comparison with past known non-working designs
Finally you get to:
5.  Comparison of the code vs the design (does it correctly implement
the design)

About step 1, you also start doing the test design (how do we test
this functionality).  A part of step 2 is "Can we test this design?"
and "is there anything that we missed in designing the test?"  From 3 
& 4, you get "These are the tests we need to run to check that it
works, because they're the ones that uncovered problems previously."
During Step 5, you do the "can this code be put through our tests?"

Note that the above also assume you have a working database of prior
practice, the bigger the better.  In the HW world, this is several
hundred years of experience, captured in books & databases, and taught
in college.  No hiding the code.  Review of what was done in the past.
What was good and bad, why.  Logical analysis to determine the
mathematical functions that the design depends on.  Best Practices, 
based on experience.  All based on having access to the design and
implementation (in other words:  the source). 


 > 
> 	 > 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.
> 
> There's another possibility, and I'm continually disappointed by  not
> hearing  anyone  (here  or in the media) mention it:  The behavior of
> MS's email software is not an accident at all.
> 
> One very real possibility is that the default enabling  of  execution
> of  incoming  code  is there because Microsoft (and some of their big
> customers) are using it.  There have been several reports from people
> who have used line monitors and traffic-analysis programs to discover
> what was going over the line, and reported seeing detailed  lists  of
> the contents of their hard disk going out to an MS address.
> 
> The fact that MS hasn't fixed the problem could very well be  because
> they  and  others  are  using  their  scripting capability to collect
> information from users' machines and send it to  interested  parties.
> If they were doing this, how would you know?  Can it be blocked?  Not
> by your typical user.
> 
> There is a large and growing market for  this  sort  of  information.
> Unless  we  know  otherwise,  we  should  assume that any binary-only
> software contains code that will report back to headquarters on where
> and  how  it  is being used.  Running incoming scripts, as MS Outlook
> does, is one easy way of implementing such features, but it far  from
> the only way it can be done.
> 
Note that MS has now released a "beta" patch for Outlook:
http://www.officeupdate.microsoft.com/2000/articles/out2ksecarticle.htm
Note that this "beta" patch strips attachments off of email.  It
also breaks Office 2000.  With the warning to not use it in a
production environment.  And doesn't solve the real problem, just
patches around it.  And yet, the GNOME folks, in gnumeric,
managed to build a sandbox for VB.  For free.  Makes you wonder,
doesn't it?
see also the slashdot discussion:
http://slashdot.org/articles/00/05/16/1232220.shtml


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