> > Contrast this method with the more common approach where once the
> > program is coded, the engineer immediately tries to compile it. The
> > compiler then leads the engineer by the nose from one problem to the
> > next. When the program finally compiles, the engineer is so relieved
> > that the immediate desire is to see if it will run. One of the best
> > clues that a shop follows this approach is complaints about how slow the
> > compilers are."
> > -- Watts S. Humphrey
> > A Discipline for Software Engineering
On the other hand, ....
I make lots of fat-fingered* typos. Half of them I catch myself before I
get to the next line. The other half, I just can't for some reason see
them until either a couple of days have elapsed or the compiler points
them out. Now if I were to discipline myself to not touch the compiler
until after peer review, I would be wasting the time of all the
reviewers. Plus probably missing some "real" defects because the
reviewers are distracted by all the nits. (I say "real" because a program
that won't compile can't crash the system.)
It is counter-productive to stare at a printout or screen for twenty
minutes and see nothing wrong, when a compiler can tell you in twenty
seconds that you have an apostrophe where you need a semicolon, or an
extra parenthesis, or ....
But as soon as (or even before) all the typos are fixed, a genuine review
would certainly be a good thing.
* you can call 'em fat-headed if you want, I'm think-skinned (or