Chapter 21. Collaborative Construction

cc2e.com/2185

Contents

• Overview of Collaborative Development Practices page 480

• Pair Programming page 483

• Formal Inspections page 485

• Other Kinds of Collaborative Development Practices page 492

Related Topics

• The software-quality landscape: Chapter 20

• Developer testing: Chapter 22

• Debugging: Chapter 23

• Prerequisites to construction: Chapters 3 and 4

You might have had an experience common to many programmers. You walk into another programmer's cubicle and say, "Would you mind looking at this code? I'm having some trouble with it." You start to explain the problem: "It can't be a result of this thing, because I did that. And it can't be the result of this other thing, because I did this. And it can't be the result of wait a minute. It could be the result of that. Thanks!" You've solved your problem before your "helper" has had a chance to say a word.

In one way or another, all collaborative construction techniques are attempts to formalize the process of showing your work to someone else for the purpose of flushing out errors.

If you've read about inspections and pair programming before, you won't find much new information in this chapter. The extent of the hard data about the effectiveness of inspections in Section 21.3 might surprise you, and you might not have considered the code-reading alternative described in Section 21.4. You might also take a look at Table 21-1, "Comparison of Collaborative Construction Techniques," at the end of the chapter. If your knowledge is all from your own experience, read on! Other people have had different experiences, and you'll find some new ideas.

Table 21-1. Comparison of Collaborative Construction Techniques

Property	Pair Programming	Formal Inspection	Informal Review (Walk-Throughs)
Defined participant roles	Yes	Yes	No
Formal training in how to perform the roles	Maybe, through coaching	Yes	No
Who "drives" the collaboration	Person with the keyboard	Moderator	Author, usually
Focus of collaboration	Design, coding, testing, and defect correction	Defect detection only	Varies
Focused review effort looks for the most frequently found kinds of errors	Informal, if at all	Yes	No
Follow-up to reduce bad fixes	Yes	Yes	No
Fewer future errors because of detailed error feedback to individual programmers	Incidental	Yes	Incidental
Improved process efficiency from analysis of results	No	Yes	No
Useful for nonconstruction activities	Possibly	Yes	Yes
Typical percentage of defects found	40 60%	45 70%	20 40%