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 -> spend more time fixing than writing ~ 95% correct is fastest • Later Change is MUCH more expensive • 1 -> 60 Ratio!!!

3. We haven’t 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 they’re 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 -> 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 they’re 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”.