Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Peer Code Review:  An Agile Process
Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com  http://twitter.com/smartbears
Code  Collaborator codecollaborator.com
Code  Collaborator codecollaborator.com
 
 
 
But is code review  really  Agile?
Individuals and interactions  over processes and tools  Working software  over comprehensive documentation  Customer colla...
Individuals and interactions  over processes and tools  Working software   over comprehensive documentation  Customer coll...
Working software is the primary measure of progress.   Manifesto Principles - I
Working software  is the primary measure of progress.   Manifesto Principles - I
Getting to Working Software
Behaviors <ul><li>Requirements </li></ul><ul><li>Design </li></ul><ul><li>Architecture </li></ul>
Behaviors <ul><li>Coding </li></ul>
Behaviors <ul><li>Coding </li></ul>
Professional Writers Have Editors
 
Spell Czech: Good, butt knot enough
ROI: The Experiment
Rule of Bug: Earlier == Cheaper What if we had Peer Review? ? ? ?
$152k, down from $368k 32, down from 194
Move the Feedback
Agile processes promote sustainable development.  The sponsors, developers, and users should be able  to maintain a consta...
Agile processes promote  sustainable development.  The sponsors, developers, and users should be able  to maintain a const...
Agile processes promote   sustainable development.   The sponsors, developers, and users should be able  to  maintain a co...
Agile processes promote   sustainable development.   The sponsors, developers, and users should be able  to maintain a con...
Bus Number >= 2
Collective Code Ownership
Continuous attention to technical excellence  and good design enhances agility.  Manifesto Principles - III
Continuous attention to  technical excellence  and  good design  enhances agility.   Manifesto Principles - III
The Ego Effect
 
Continuous Learning
Are the meetings necessary?
Can We Avoid:
Formal Inspections Michael Fagan, IBM, 1976
Fagan Phases = Meeting
 
 
 
 
4%
Fagan Phases = Meeting
Code review  without  meetings?
 
Adapt and Adjust
Over-the-Shoulder
Over-the-Shoulder Easy / Free Interruption No info Recorded Walk-through
Email
Email Easy / Free No Interruption / Remote Conversation Tracking Info. Hard to Retrieve No End?
Pair Programming
Pair Programming No Tools or Workflow Deep Thought Big Time Commitment No Info. Recorded Too Close
Tool-Assisted Review
Reviewers Identify Changes Package/Deliver Organize Communication Track Defects Audit Trail Reports Automatic Metrics Hapl...
Tool-Assisted Review Collection Communication Chronicling Install and Maintain Time or Money
Tools Code Collaborator Commercial Crucible Commercial Review Board Open-Source Rietveld/Gerrit Open-Source
What’s the most efficient use of time?
Cisco® MeetingPlace® Case Study 3,200,000 lines of code 2,500 reviews 50 developers 10 months San Diego, Bangalore, Budape...
CodeReviewBook.com
60-90 minutes max Time (minutes) Defects Found
Go slowly:  200-500 LOC/hour
Not too much:  200-400 LOC
Other Timely Topics
Checklist for Checklists 7    2 (George Miller, 1952) No obvious stuff Nothing that can be automated Stuff that’s easy to...
Version Control: Before or after check-in?
But won’t people  hate  doing code reviews?
Start Slowly
Selected Code Only Stable branch Core modules/10 scariest files Unit tests
No Flaming
It’s All About  Tone Ask, Don’t Tell Don’t Accuse We All Make Mistakes
Careful Use of Metrics
We’re Agile -  No  Metrics!
Numbers, Numbers, Numbers LOC Time Defects Inspection and Defect Rates Defect Density
 
Review the Code  Not  the Coder
Properly Adjusted, Code Review  is  Agile
Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com  http://twitter.com/smartbears
Upcoming SlideShare
Loading in …5
×

Agile Austin - Peer Code Review An Agile Process

3,887 views

Published on

Slides from Gregg Sporar's presentation on peer code review at the January 2010 meeting of Agile Austin. More information available here: http://blog.smartbear.com/the_smartbear_blog/2010/01/is-pair-programming-like-junior-high-sex.html.html

Published in: Technology

Agile Austin - Peer Code Review An Agile Process

  1. 1. Peer Code Review: An Agile Process
  2. 2. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears
  3. 3. Code Collaborator codecollaborator.com
  4. 4. Code Collaborator codecollaborator.com
  5. 8. But is code review really Agile?
  6. 9. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Manifesto
  7. 10. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Manifesto
  8. 11. Working software is the primary measure of progress. Manifesto Principles - I
  9. 12. Working software is the primary measure of progress. Manifesto Principles - I
  10. 13. Getting to Working Software
  11. 14. Behaviors <ul><li>Requirements </li></ul><ul><li>Design </li></ul><ul><li>Architecture </li></ul>
  12. 15. Behaviors <ul><li>Coding </li></ul>
  13. 16. Behaviors <ul><li>Coding </li></ul>
  14. 17. Professional Writers Have Editors
  15. 19. Spell Czech: Good, butt knot enough
  16. 20. ROI: The Experiment
  17. 21. Rule of Bug: Earlier == Cheaper What if we had Peer Review? ? ? ?
  18. 22. $152k, down from $368k 32, down from 194
  19. 23. Move the Feedback
  20. 24. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II
  21. 25. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II
  22. 26. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely . Manifesto Principles - II
  23. 27. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely . Manifesto Principles - II
  24. 28. Bus Number >= 2
  25. 29. Collective Code Ownership
  26. 30. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III
  27. 31. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III
  28. 32. The Ego Effect
  29. 34. Continuous Learning
  30. 35. Are the meetings necessary?
  31. 36. Can We Avoid:
  32. 37. Formal Inspections Michael Fagan, IBM, 1976
  33. 38. Fagan Phases = Meeting
  34. 43. 4%
  35. 44. Fagan Phases = Meeting
  36. 45. Code review without meetings?
  37. 47. Adapt and Adjust
  38. 48. Over-the-Shoulder
  39. 49. Over-the-Shoulder Easy / Free Interruption No info Recorded Walk-through
  40. 50. Email
  41. 51. Email Easy / Free No Interruption / Remote Conversation Tracking Info. Hard to Retrieve No End?
  42. 52. Pair Programming
  43. 53. Pair Programming No Tools or Workflow Deep Thought Big Time Commitment No Info. Recorded Too Close
  44. 54. Tool-Assisted Review
  45. 55. Reviewers Identify Changes Package/Deliver Organize Communication Track Defects Audit Trail Reports Automatic Metrics Hapless Developer Version Control
  46. 56. Tool-Assisted Review Collection Communication Chronicling Install and Maintain Time or Money
  47. 57. Tools Code Collaborator Commercial Crucible Commercial Review Board Open-Source Rietveld/Gerrit Open-Source
  48. 58. What’s the most efficient use of time?
  49. 59. Cisco® MeetingPlace® Case Study 3,200,000 lines of code 2,500 reviews 50 developers 10 months San Diego, Bangalore, Budapest s
  50. 60. CodeReviewBook.com
  51. 61. 60-90 minutes max Time (minutes) Defects Found
  52. 62. Go slowly: 200-500 LOC/hour
  53. 63. Not too much: 200-400 LOC
  54. 64. Other Timely Topics
  55. 65. Checklist for Checklists 7  2 (George Miller, 1952) No obvious stuff Nothing that can be automated Stuff that’s easy to forget EXAMPLE: Errors handled properly in all cases
  56. 66. Version Control: Before or after check-in?
  57. 67. But won’t people hate doing code reviews?
  58. 68. Start Slowly
  59. 69. Selected Code Only Stable branch Core modules/10 scariest files Unit tests
  60. 70. No Flaming
  61. 71. It’s All About Tone Ask, Don’t Tell Don’t Accuse We All Make Mistakes
  62. 72. Careful Use of Metrics
  63. 73. We’re Agile - No Metrics!
  64. 74. Numbers, Numbers, Numbers LOC Time Defects Inspection and Defect Rates Defect Density
  65. 76. Review the Code Not the Coder
  66. 77. Properly Adjusted, Code Review is Agile
  67. 78. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears

×