Plea for help: The detriment of using Microsoft products

[mikebw at colossus.bilow.com (Mike Bilow)]

This is just outright management failure.  See, for example:

	http://www.oualline.com/col/review.html

I can assure you that people hate to see me drop in on code reviews.  It
takes significant effort to follow someone else's code, and it requires
some practice on their part of explain it.  Arguing about the curly braces
should be stopped by the review leader.  On the other hand, I have seen
people turn white as a sheet when I ask questions such as, "Do you think 
there would be any benfit to unrolling that loop?"  Ultimately, reviewing
code is a lot like teaching.

-- Mike


On 2000-05-16 at 14:29 -0400, John Chambers wrote:

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


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