Collaborative Development

Collaborative construction refers to pair programming, formal inspections, informal techinical reviews and document reading, as well as other techniques in which developers share responsibility for creating code and other workproducts.

The primary purpose of collaborative construction is to improve software quality.
Benifits:
1. Better code quality arises from multiple sets of eyes seeing the code and multiple programmers working on the code.
2. The risk of someone leaving the project is lower because multiple people aer familiar with each section of code.
3. Defect-correction cycles are shorter overall because any of several programmers can potentially be assigned to fix bugs on an as-available basis

Keys to success with pair programming
1. Support pair programming with coding standards.
2. Don't let pair programming turn into watching.
3. Don't force pair programming of the easy stuff.
4. Rotate pairs and work assignments regularly.
5. Encourage pairs to match each other's pace.
6. Make sure both partners can see the monitor.
7. Don't force people who don't like each other to pair.
8. Avoid pairing all newbies.
9. Assign a team leader.

Benefits of pair programming
1. It holds up better under stress than solo development. Pairs help keep each other honest and encourage each other to keep code quality high even when there's pressure to write quick and dirty code.
2. Code quality improves.
3. It produces all the other general benefits of collaborative constructions including disseminating corporate culture, mentoring junior programmers and fostering collective ownership.

Formal Inspections
An inspection is a specific kind of review that has been shown to be extremely effective in detecting defects and to be relatively economical compared to testing.

Roles during an inspection
1. Moderator. Responsible for keeping the inspection moving at a rate that's fast enough to be productive but slow enough to find the most errors possible. This person must be technically competent--not necessarily an expert in the particular design or code under inspection, but capable of understanding relevant details. This person manages other aspects of the inspection, such as distributing the design or code to reviewed and the inspection checklist, setting up a meeting room, reporting inspection results.
2. Author. The person who wrote the design or cod palys a relatively minor role in the inspection. Duties are to explain parts of the design or code that are unclear.
3. Reviewer. A reviewer is anyone who has a direct interest in the design or code but who is not the author. The role of the reviewer is to find defects.
4. Scribe. The scribe records errors that are detected and the assignments of action items during the inspection meeting.
5. Management. Not usually a good idea.

General procedure for an inspection
1. Planning. The author gives the design ro code to the moderator. The moderator decides who will review the material and when and where the inspection meeting will occur, and then distributes the design or code and a checklist that focuses the attention of the inspectors.
2. Overview. When the reviewers aren't familiar with the project they are reviewing, the author can spend up to an hour or so describing the technical environment withing which the design or code has beeng created.
3. Preparation. Each reviewer works alone for about 90 minutes to beconde familiar with the design or code.
4. Inspection meeting. The moderator chooses someone to paraphrase the design or read the code. During the presentation, the scribe records errors as they are detected.
5. Inspection report. Withing a day of the inspection meeting, the moderator produces an inspection report that lists each defect.
6. Rework. Resolve each defect on the list.
7. Follow-up. The moderator is responsible for seeing that all rework assigned during the inspection is carried out. If more than 5% of the design or code needs to be reworked, the whole inspection process should be repeated.
8. Third-hour meeting. Can hold an informal, third-hour meeting to allow interested parties to discuss solutions after the official inspection is over.

Egos in inspection: The point of the inspection itself is to descover defects in the design or code. It is not explore alternatives or to debate about who is right and who is wrong. The point is most certainly not to criticize the author of the design or code.

Other kinds of collaborative development practices.
1. Walkthroughs. Is a popular kind of review, involves two or more people discussing a design or code.
2. Code reading. Is an alternative to inspection and walkthroughs.