1. Software Development Quality Practices Code Reviews Inspections Walkthroughs

2. Overview What is a Software Quality Review Why are Reviews needed? When do you do them? “Where” do you do them? How: Types of Reviews What is a Software Quality Review?  “…a critical evaluation of an object” [Collofello88]  “Inspections are a formal, efficient, and economical method of finding errors in design and code” [Fagan76]  “A process or meeting during which a software product is presented to project personnel, management, users, customers, user representatives, or the other interested parties for comment or approval” [IEEE1028-1997]

3. Why are Reviews Needed? As a Supplement to Testing  It is not possible to [white box] test everything  Testing does not find all types of quality issues  Code Reviews find 65% of latent defects, testing 30% * Together reviews & formal testing often achieve > 95% As a Communication Vehicle  Communicate quality and status to stakeholders (customers, users, managers, etc.)  Communicate quality and design information to peers As a Training Vehicle  Benefit to the developer All of these reasons point to Quality Improvement *Capers Jones

4. Motivating reviews What does this chart* tell you? Formal inspections are the single best method Inspections + testing find > 95% of defects *Capers Jones Jan. 2008

5. Justifying Reviews  HP estimates saving $24.1M/year (Grady/Van Slack ‘94)  AT&T reports cost reductions of an order of magnitude plus a 14% productivity increase (Humphrey ‘89)  Bell Northern Research inspected 2.5M LOC and estimated 33 hours saved per defect. Finding defects through inspection 2-4 x faster than testing (Russel ‘91)  IBM 1 hour of inspection saved 20 hours of testing and 82 hours of rework  Primark Investment Mgmt Svcs indicated 30K labor hour savings & 5x less errors in a 5 year period (Holland ‘99)  Imperial Chemical maintenance costs of inspected code were 10x better than uninspected code (Gilb/Graham ‘93)  Litton Data Systems invested 3% project effort and received a 30% error reduction (Madachy ‘95) Inspections accepted as the #1 quality technique

6. When do you review? Understand Quality “Touchpoints” in the context of your software lifecycle process Understand what the review’s objectives are Requirements: reviews after stakeholder touchpoints Analysis: reviews with customers and peers Implementation: reviews with peers, users, & customers Test: QA test scripts reviewed by stakeholders Deployment: procedures reviewed by architect/PM

7. “Where” to perform reviews “Where” a strange question, but consider…  Some reviews (audits) are conducted offsite in front of external stakeholders  Some reviews are conducted locally but in a formal meeting environment  Some reviews are informal and occur at your desk, or in front of a whiteboard, etc. The key point here is “level of formality”  More formal reviews have a more burdensome process, but this does not mean they are a bad thing  Informal reviews may suffer from being “too casual”

8. How: Types of Reviews IEEE 1028-1997  Management Reviews  Technical Reviews  Inspections  Walk-throughs  Audits The key is in the level of granularity, and to a certain extent the level of formality. You want to leverage level of quality gained versus time and cost factors Code Complete 2: Formal Inspections Walkthroughs Code Reading Dog-and-Pony Shows Peer Reviews in Software [Wiegers]: Inspections Team Review Walkthroughs Pair Programming Peer deskcheck / passaround Ad hoc review

9. Review Spectrum Types of code reviews are a function of formality  More formality --> more defects found --> higher quality  Less formality --> fewer defects found --> less quality Don’t ignore the social issues!  Nobody enjoys having their work put under a microscope  Emphasize the benefits to the reviewee  A quality culture reinforces “we’re all in this together”, and reduces the potential for finger-pointing Graph taken from Wiegers Ch. 3 (2001)

10. The Basic Inspection Process Code Review Process Plan the review; cover all the logistics System overview presented to inspection team Code and associated documents are distributed to inspection team in advance so they can prepare Inspection takes place and discovered errors are noted Modifications are made to repair discovered errors Re-inspection may or may not be required

11. Formal Inspections [Fagan,Wiegers] Inspection teams  Made up of at least 4 members  Author of the code being inspected  Inspector who finds errors, omissions and inconsistencies  Reader who reads the code to the team  Moderator chairs the meeting and notes discovered errors  Other roles are Scribe and Chief moderator Inspection checklists  Checklist of common errors should drive the inspection  Error checklist is programming language dependent  The 'weaker' the type checking, the larger the checklist  Ex: initialization, constant names, loop conditions, etc.

12. Formal Inspections Benefits:  Proven to reduce defects  Forcing one to prepare for such a meeting provides motivation to improve quality  Visibility and openness of quality issues Drawbacks  Can be socially distressing  Employees worry it becomes a basis for job evaluation  Different participants may have different perspectives on quality  Scheduling and cost

13. Team Reviews [Wiegers] “Inspection-lite”  Similar structure to inspections, but less formality Overview and follow-up may be skipped  Roles are still defined May be more “loose” Number of participants may vary  Goal is still project quality Benefits:  Less overhead on the process  Lessens social challenges due to less formality Drawbacks  Fewer defects may be found

14. Walkthroughs Developer presents code to a small group of peers  Developer describes software  Developer describes how it works “Walks through the code”  Free-form commentary/questioning by colleagues Benefits  Many eyes, many minds  Purpose is to benefit the author Drawbacks  Does not necessarily address the quality needs of the project

15. Pair Programming Software development practice providing continual review  Two developers, 1 computer, alternating between driver and observer  “If reviews are good, lets do them all the time” – eXtereme Programming Roles  Driver – focus attention on completing task  Observer – ideas for improvement, guidance, safety net Benefits  Continuous improvement to design quality  Mentoring and training  Improved moral  Better and more consistent discipline and time management  Fewer interruptions Drawbacks  Costs – tutoring time, may not see benefits if both pairs are strong developers  Interpersonal – egos, annoying habits, conflicts (work style)  Has only been applied to code artifacts

16. Summary From Wiegers (2001):

17. Summary – Dr. Gary’s Top 10 Tips 1.Do them! Proven best technique for improving quality 2.Do not tie into employee review process 3.Clarify objectives and the level of granularity of review 4.Have coding standards in place first (rubrics) 5.Keep it fast & light (agile); don’t sweat small stuff 6.Look for things your unit tests and tools won’t find! 7.Do as part of the quality process, not as a milestone 8.Track how many defects are found/removed 9.Choose which code to review by priority (complexity, use) 10.Do something! And follow up!