Software Defect Prevention via Continuous Inspection
Avoid the Zone of Chaos: Economics of Quality andProductivity via Code ReviewReducing software development risk and costwhile improving speed, quality andmaintainability by applying review at all levelsPresented by: Joshua GoughAtlanta ALT.NET Meetuphttp://www.meetup/com/AtlAltDotNet6/19/2012
Topic Outline● Avoiding the Ultimate Risk● Software Development Processes● Risks associated with poor code-review and lack of defect prevention● Automated .NET tools to support "continuous inspection", code-review, and defect prevention● Demo of static source-code analysis with Visual Studio and NDepend
Avoiding The Ultimate Risk● How to validate that youre building the product your customers or users want and need?● What untested assumptions and risks can lurk in requirements and design docs?● What kinds of reviews can happen before or in parallel with coding to test assumptions and mitigate risks?
Types of Code Review● Formal code review: involves a careful and detailed process with multiple participants and multiple phases: Example: Fagan Inspection● Over-the-shoulder : One developer looks over the authors shoulder as the latter walks through the code.● Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.● Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.● Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review.
Productivity Reasons: Faster Schedule t! Spo eet SwRelationship between defect rate and development time. As a rule,the projects that achieve the lowest defect rates also achieve theshortest schedules. -- Capers Jones
Pair Programming● Agile software development technique wherein two programmers work together at one workstation● One drives and writes codes while the other observes (or navigates) and reviews each line of code● The two programmers switch roles frequently● While reviewing, the observer also considers the strategic direction of the work in order to: ○ Devise ideas for improvements and likely future problems to address ○ Free the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide
But, What Does the Science Say?● Isolated studies of pair-programming reveal results ranging all across the map● Some meta-analyses also reveal wide- ranging results● I suspect the answer to be "It depends", therefore proceed without dogma and use pragmatism
Study Summary● 48% increase in correctness for complex systems ○ No significant time difference● Simple systems had 20% time decrease ○ No significant correctness difference● Overall no general time reduction or correctness increase ○ But an overall 84% effort increase● Limitations: this was a one day experiment with 99 individuals and 98 pairs How would working together longer affect results?
1. Review fewer than 200-400 lines of code at a time.
2. Aim for an inspection rate of less than 300-500 LOC/hour
3. Take enough time for a proper, slow review, but not more than 60-90 minutes K e y
4. Authors should annotate source code before the review
Additional Tactical Tips...● 5. Establish quantifiable goals for code review and capture metrics so you can improve your processes● 6. Checklists substantially improve results for both authors and reviewers● 7. Verify that defects are actually fixed!
And Managerial Tips...● 8. Managers must foster a good code review culture in which finding defects is viewed positively● 9. Beware the “Big Brother” effect● 10. The Ego Effect: Do at least some code review, even if you dont have time to review it all
11.Lightweight-style code reviews are efficient, practical, and effective at finding bugs
Many Thanks to SmartBear Software!(See CodeCollaborator Free Trial and Jason Cohens Free Book) Free!