Research and guidance for educing software development risk and cost while improving speed, quality and maintainability by applying review at all levels.

1. Avoid the Zone of Chaos:
Economics of Quality and
Productivity via Code Review
Reducing software development risk and cost
while improving speed, quality and
maintainability by applying review at all levels
Presented by: Joshua Gough
Atlanta ALT.NET Meetup
http://www.meetup/com/AtlAltDotNet
6/19/2012

2. 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

3. Avoiding The Ultimate Risk
● How to validate that you're 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?

4. Danger! Don't Go There!
Say
Wha
t?

5. Royce Strawman Waterfall Model

6. Royce's Observations

7. Final Royce Model
(Shame on our industry for not reading his whole paper)

8. Generic Iterative and Incremental Model

9. Boehm Spiral Model

10. Generic Agile

11. Extreme Programming (XP) Feedback Loops

12. Scrum Agile Process Framework

13. Whirlpool Model
(A "violent water metaphor" we can live with and enjoy)

14. Scrum Agile Process Framework

16. Let's Review...

17. Traditional: Known | Known

18. Agile: Known | Unknown

19. Lean Startup: Unknown| Unknown

20. And Now: Code Review...

21. 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
author's 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.

22. Economic Reasons : Defect Cost Increase

23. Productivity Reasons: Faster Schedule
t!
Spo
eet
Sw
Relationship between defect rate and development time. As a rule,
the projects that achieve the lowest defect rates also achieve the
shortest schedules. -- Capers Jones

24. Cisco Case Study Data : Defect Counts

25. Formal Code Review

26. Hope This Guy Gets Lost in Elevator

27. Email Pass-Around Pre Check-In

28. Email Pass-Around Post Check-In

29. Email Pass-Around Code Review
(Pray Uncle Bob Doesn't Get The Email, Unless You Crave Discipline! )

30. Over-The-Shoulder Walkthrough

31. Don't Be This Guy (Either of Them!)

32. 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

33. In Other Words...

34. 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

35. Example Study

36. 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?

37. Tool-Assisted Code Review!

38. Demo: Visual Studio Code Analysis

39. Demo: NDepend Critical Warnings

40. 11 Lessons from SmartBear Cisco Case Study

41. 1. Review fewer than 200-400 lines of code at a time.

42. 2. Aim for an inspection rate of less than 300-500 LOC/hour

43. 3. Take enough time for a proper, slow review, but not
more than 60-90 minutes
K
e
y

44. 4. Authors should annotate source code before the review

45. 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!

46. 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 don't have time to review
it all

47. 11.Lightweight-style code reviews are efficient,
practical, and effective at finding bugs

48. Many Thanks to SmartBear Software!
(See CodeCollaborator Free Trial and Jason Cohen's Free Book)
Free!

49. Contact
● Meetup: http://www.meetup.com/AtlAltDotNet
● Email: jsgough@gmail.com
● Web: http://agilefromthegroundup.blogspot.com