Plea for help: The detriment of using Microsoft products

[ggallen at slackinc.com (George Gallen)]

One thing I have found with C, is that at first, get the
program running, use simple statements and lots o indenting,

Then once it's running, start modifying it to run faster, by
trying place multiple operations and using other shortcuts
which run quicker, make for less code, but make it down right
obnoxious to debug.

George

>-----Original Message-----
>From: Jeffry Smith [mailto:smith at missioncriticallinux.com]
>Sent: Tuesday, May 16, 2000 3:18 PM
>To: John Chambers
>Cc: Kevin D. Clark; GNHLUG; BLU Users' Group
>Subject: Re: Plea for help: The detriment of using Microsoft products 
>
>
>
>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). 
>
>
>
-
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).