Review Techniques

1
Review Techniques

• Why Review
• Review vs Testing
• Type of Reviews
• Inspections
• Walkthroughs
• Code Reading
• Pair Programming

2
Quality Assurance Fundamentals

• QA techniques provide critical support for
  maximum development speed
• If too many defects -gt spend more time fixing
  than writing

95 correct is fastest

• Later Change is MUCH more expensive
• 1 -gt 60 Ratio!!!

3
We havent got time(for more testing, for review)

• A decision not to focus on defect detection early

• is a decision to postpone defect detection until
  later in the project,

• WHEN IT WILL BE MUCH MORE EXPENSIVE IN TIME AND
  

4
QA technique 1 - Testing

• Unit testing - finds 10-50 of defects
• Average 25
• System testing finds 20-60
• Average 45
• Cumulative - usually less than 60
• Finds errors late - when theyre more expensive
  to fix

5
QA Technique 2 - Reviews

• Find 60 - 90 of errors
• Finds them earlier
• Is 3 - 10 times more cost-effective than testing

6
Some Published Results

• 1-line maintenance changes
• 55 error -gt 2 error
• 2, 11 programs, same people
• 5 without reviews 4.5 errors / 100 loc
• 6 with reviews 0.82 errors / 100 loc
• Aetna found 82 of errors using inspections,
  25 productivity increase
• ATT 14 productivity increase, 90 defect
  decrease
• JPL estimates 25,000 saving PER INSPECTION

7
Personal Experience (RB)

• Reviewed modules were robust, easy to maintain
• Compare -a non-reviewed project was 4 times
  budget, Acceptance phase took 6 months
• (budgeted 1 month)
• Many indirect advantages of reviewing
• Author more likely to have Do it right first
  time attitude because code will be reviewed by
  another

8
Extra Benefits of Reviews

• Education - spread skill, experience
• Promote Standards and Good Practice
• Assess Quality and Progress
• Promote teamwork
• Reviews apply at all stages

9
Review or Testing?

• Complementary - Find different types of errors
• Best results when BOTH used

Detected by Reviews
Detected byTesting
10
Types of Reviews

• Inspections
• Formal, Checklists, focus on defect detection,
  defined roles (at least 3 people), Data collected
• Walkthroughs
• Less formal, usually hosted by author, emphasis
  on improvement, learning
• Code Reading
• Less emphasis on meeting. Can be done remotely
• Pair Programming
• Continuous review two programmers work together
  at one computer

11
Inspection Roles

• Moderator (Chairman)
• Author
• Reviewer. May be several
• Scribe________________________
• Management - NO WAY
• Moderator may be scribe, otherwise no combination
  of roles

12
Inspection Procedure

• Planning
• Overview
• Preparation (eg Code Reading)
• Inspection meeting
• Inspection Report
• Repair
• Follow up

13
Egos in Inspections

• Style and Opinions
• How to express comments
• What about Suggested Improvements

14
The Right Attitude is Vital!

• Too much ego will destroy cooperation
• Too little ego (confidence) uncritical
  acceptance of others views. Quality improvements
  will be missed.
• Vital to have right attitude
• Cooperative, value others contributions
• Objective. Focus on team goal

15
When to Inspect
Who decides? Probably Author
Too early - Not enough done to review
productively
Too late Time has been wasted that review
would have saved Too much ego invested
Appropriate level of formality
Less
More
16
What to Inspect

• Program Code
• Specifications?
• Test Plans?

17
Walkthroughs

• Usually hosted by author
• 30-60 minutes
• Flexible
• When done well-
• slightly less effective than inspections
• can be more flexible
• When done poorly-
• more trouble than theyre worth

18
Inspection / Walkthough Comparison
19
Code Reading

• Code passed to reviewers
• Reviewed independently, each reviewer notes
  errors
• Meeting reviews error reports, no attempt to go
  through code line by line
• (Meeting may not be necessary)
• Author fixes problems

20
Pair Programming

• Two programmers work together at one computer
• One codes, the other observes
• Popular with eXtreme Programming
• If reviewing is good, then more reviewing is
  better. The extreme continuous review of
  everything.
• Pair programming sounds inefficient is it?

21
Pair Programming is it productive?

• Mostly ad-hoc stories, little good evidence
• Study results initially 40 faster, but 60
  increase in resource. After adjustment period,
  results improve - 15 increase in resource
  compared with programming alone.
• Higher quality result.
• On this basis, PP is less effective than other
  inspection techniques, but better than lone
  programming because of quality increase
• HOWEVER

22
Pair Programming and Teamwork

• Pair programming may have strong advantages in
  team building
• Anecdotal evidence Pair Programmers work well
  as a team, develop the cooperative attitudes
  essential to making any inspection technique
  work.
• Experienced pair programmers prioritize, and
  decide which parts to do in pairs, which alone.

23
Reviewing - Conclusions

• Reviewing is the most important single step you
  can take to improve quality and productivity.
• The key to success is a cooperative teamwork
  attitude
• Our product, not Your/My Program.