Re: Pair programming [ was: Re: [tlug] [OT] Good IT Resume

["Stephen J. Turnbull" <stephen@example.com>]

Josh Glover writes:

 > Interesting. I was unaware of that. Is the SEI stuff worth reading, or
 > is it overly academic and thus not of much use in the wild?

The SEI stuff per se is a set of specifications for their Capability
Maturity Model evaluations, and not worth reading unless you expect to
suffer through an SEI review.  The originator of much of the CMM stuff
is Watts Humphrey, whose "Introduction to the Personal Software
Process" is a textbook for the individual engineer wishing to apply
process improvement, metrics, and the like to his work as an
individual.  This is well-worth buying, you can read as much as you
like without missing much (few internal dependencies except on some
knowledge of software engineering, and common sense).  He also has a
much heavier, academic book, "A Discipline for Software Engineering",
which is a must-read for leaders of Intro. PSP seminars, and maybe
worth reading for anybody who does process-oriented seminars.  (Maybe
only so you'll know the conemptorary jargon.)  He also has a book on
"Managing the Software Process" which explains the CMM itself.

 > [1] http://en.wikipedia.org/wiki/Code_review
 >      Interesting. It looks like what you are talking about is "formal
 > code review", which, according to the Wikipedia article[2], is the
 > "older, traditional method of review, in which software developers
 > attend a series of meetings and review code line by line, usually
 > using printed copies of the material." Whereas what I am talking about
 > is "lightweight code review", which "typically requires less overhead
 > than formal code inspections, though it can be equally effective when
 > done properly."

The wikipedia article almost certainly was written by a programmer,
not a manager.  I'm not an expert on this stuff, but I do know that
the process people distinguish among "code review" (very formal and
chaired by someone from outside the work group, sort of like a PhD
defense), and "code inspection", which is less formal and typically
organized and chaired by somebody within the workgroup.  I would
expect that the software process folks would take "lightweight" as the
marked case, and assume a formal code review unless "lightweight" is
specified.  OTOH, you could argue that's because they're primarily
interested in truly mammoth projects (Star Wars, shuttle systems,
etc).