If you can get a good code audit, it means you have gotten several
people (3-4 at most) to spend several hours going over a segment of
code to look for anything questionable. This is an extraordinarily
effective way to find errors, but is really hard. Most people can't
do more than 100 lines or so in a session. It should be regarded
as assistance, though, not as criticism, and one of the things
that is hard about it is that the reviewers have to get into the
developer's mindset about how the code was written, not suggest
how they would have written it. The reviewer's job is to find out
if anything is questionable (and oftentimes what looks questionable
is not, once explained) in a section of code.
Given the economics and magnitude of the effort, you don't do real
code audits on throwaway code (much) and you expect some picking and
choosing of what code is being examined. It is an exhausting process
for reviewers and for the code author, and gets done after the author
has run his own desk checks and code tests. A developer who wants his
code to work right will however usually welcome such an opportunity
once it is clear that it in effect multiplies his brainpower for awhile
to get the code right. (It also gets the few reviewers familiar
enough with the code that they may be able to help find any further
problems with it later, as it is changed...but that is a secondary
effect.)
Just having someone else look at a large set of code and attempt to
evaluate it based on a short exposure to it is most likely to wind up
comparing the developer's style with the reviewer's, and findings
of such will often be wrong with respect to the original design, if the
code has been prepared appropriately for a real audit.
The real thing, where both developer and the reviewers are in there
together sweating bullets, is not adversarial, but collegial,
and those who object initially generally drop the objections by the
time they finish.
**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
people (3-4 at most) to spend several hours going over a segment of
code to look for anything questionable. This is an extraordinarily
effective way to find errors, but is really hard. Most people can't
do more than 100 lines or so in a session. It should be regarded
as assistance, though, not as criticism, and one of the things
that is hard about it is that the reviewers have to get into the
developer's mindset about how the code was written, not suggest
how they would have written it. The reviewer's job is to find out
if anything is questionable (and oftentimes what looks questionable
is not, once explained) in a section of code.
Given the economics and magnitude of the effort, you don't do real
code audits on throwaway code (much) and you expect some picking and
choosing of what code is being examined. It is an exhausting process
for reviewers and for the code author, and gets done after the author
has run his own desk checks and code tests. A developer who wants his
code to work right will however usually welcome such an opportunity
once it is clear that it in effect multiplies his brainpower for awhile
to get the code right. (It also gets the few reviewers familiar
enough with the code that they may be able to help find any further
problems with it later, as it is changed...but that is a secondary
effect.)
Just having someone else look at a large set of code and attempt to
evaluate it based on a short exposure to it is most likely to wind up
comparing the developer's style with the reviewer's, and findings
of such will often be wrong with respect to the original design, if the
code has been prepared appropriately for a real audit.
The real thing, where both developer and the reviewers are in there
together sweating bullets, is not adversarial, but collegial,
and those who object initially generally drop the objections by the
time they finish.
**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************
[ reply ]