Research and guidance for educing software development risk and cost while improving speed, quality and maintainability by applying review at all levels.
The Codex of Business Writing Software for Real-World Solutions 2.pptx
Software Defect Prevention via Continuous Inspection
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?
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.
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
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
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
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?
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