EKON 16: Software Quality 101

EKON 16: Software Quality 101

The slides for the Software Quality talk at EKON 16.

Ebeb5d8fd081058ba8df73d378bf83d7?s=128

Sebastian P.R. Gingter

November 06, 2012
Tweet

Transcript

  1. Software Quality 101 Sebastian P.R. Gingter - @PhoenixHawk EKON 16,

    November 2012 Slides: https://speakerdeck.com/u/phoenixhawk
  2. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Why Quality?
  3. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance
  4. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance always costs
  5. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Defects always cost
  6. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    „Software quality measures always are a trade-off between insurance and defect costs.“
  7. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Quality costs money
  8. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Time = money
  9. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Focus: little overhead for good gain
  10. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Basic requirements
  11. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Source Control
  12. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    CVS / VSS
  13. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    SVN / Git / Hg / TFS
  14. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Bug tracking
  15. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Bug & Feature tracking
  16. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    EXCEL
  17. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    OnTime, YouTrack, Mantis, Jira, Bugzilla, Roundup, Redmine, FogBugz, you name it...
  18. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Ideally: Integrated with SCM
  19. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Ideally: Integrated with time recording
  20. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Bug: Description Repro Reason Solution Time spent
  21. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Feature: Precise description Documentation Approach Time spent Description of tests
  22. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Checkins only with Task #ID
  23. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Continous integration
  24. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Ideally: Integrated with SCM & tracking
  25. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Build every single checkin
  26. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Enables you to test every single checkin
  27. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    WHY ?
  28. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    You want control
  29. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Traceability
  30. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Discipline
  31. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Productivity & Diligence
  32. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Traceability Discipline Productivity & Diligence
  33. Why SCM & Bugtracking? •  Even simple changes WILL have

    side-effects •  You can see WHAT the change was in SCM •  You need to know WHY the change was made hence the Bug # (and SCM-/Tracking integration) •  Only then you can reliably fix the side-effect without breaking •  previous bug fixes •  other features November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  34. Why continuous integration? •  Fail fast as insurance •  Fastest

    possible feedback on •  THAT something broke •  and from the logs also WHAT broke November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  35. Why continuous integration? •  Why is that good? •  Developer

    is still in the topic •  She‘s able to directly fix the issues without having to re-think the situation when a bug report comes in a few days (or weeks) later •  Other devs know of the problem and don‘t check out broken versions that causes them problems •  Enables automated testing November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  36. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    SCM Tracking CI
  37. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Traceability Discipline Productivity & Diligence
  38. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    One more thing:
  39. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Clean code
  40. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Not the movement
  41. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Simply ‚clean‘ code
  42. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Only ‚but‘: Requires discipline
  43. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Easy & cheap measures
  44. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Focus development process on quality
  45. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Don‘t do post-QA
  46. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Automate
  47. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Automate recurring tasks
  48. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Automate error-prone tasks
  49. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Automate tedious tasks
  50. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Change tools only where required
  51. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Process
  52. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Eliminate possible error sources
  53. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Introduce insurances
  54. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance: „stable branches“
  55. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Design your branching model
  56. „stable branches“ •  Ensure that you are able •  to

    release a •  stable version •  at every given moment in time November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  57. Requirement for „stable branches“ •  Only develop in branches, never

    in trunk/master •  Features •  Bug fixes •  Reintegrate into release-branch only if 100% sure •  that it‘s tested •  you‘re confident in stability November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  58. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Prevents ‚half baked‘ features
  59. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Prevents blocked hotfix releases
  60. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Prevents accidentally releasing crap
  61. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Enables delaying release of unfinished stuff
  62. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Only little overhead in branching / merging
  63. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Small ‚but‘: Requires good SCM tooling
  64. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance: Training
  65. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Give Devs training time
  66. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    not too much
  67. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    distracting
  68. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Time = money
  69. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Alternative: Give access to courses
  70. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Most important
  71. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Allow opportunities to fail
  72. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    learning by failure
  73. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Hacking nights, couch coding
  74. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    In spare time
  75. Benefits of training •  Better developers •  Less errors • 

    Higher motivation November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  76. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance: Review
  77. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Caution: problematic
  78. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Intuitive: Review before reintegrate
  79. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Styleguide correctly used?
  80. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    There‘s an app for that!
  81. Tooling for Delphi •  http://www.socksoftware.com/codehealer.php •  http://www.peganza.com/products_pal.htm •  http://sourceforge.net/projects/dca/ • 

    http://docs.codehaus.org/display/SONAR/Delphi+Plugin November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  82. Tooling for .NET •  FxCop •  StyleCop November 2012 -

    EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  83. Measurement of quality with code reviews? November 2012 - EKON

    16 Sebastian P.R. Gingter - @PhoenixHawk
  84. Shoot the Developer! November 2012 - EKON 16 Sebastian P.R.

    Gingter - @PhoenixHawk
  85. Amusement: Joe O‘Brien & Jim Weirich: Ruby code review November

    2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  86. Code Reviews You‘re probably doing it wrong! •  Code reviews

    are distracting •  WTF WTF WTF •  „Look at that! Can you tell me what he meant by this?“ •  Reviewer needs too much time to get in the code •  Unproductive and time consuming •  Reviewer could mob developer •  „You‘re not working with our guidelines“ •  „But *Everyone* knows that {very special way of doing things here}“ November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  87. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Don‘t do them
  88. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    WTF?
  89. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Yes: Don‘t do them!
  90. IF you want to do them: •  do „Over the

    shoulder“ reviews •  Developer seeks reviewer in person •  Developer explains to reviewer •  Reviewer asks questions and points to possible problems •  Developer takes notes •  Developer fixes •  Developer checks in November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  91. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    So, what else, if not code reviews?
  92. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance
  93. Pair programming November 2012 - EKON 16 Sebastian P.R. Gingter

    - @PhoenixHawk
  94. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    But!!! Expensive!!!
  95. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Hell, NO! Source: http://alistair.cockburn.us/Costs+and+benefits+of+pair+programming
  96. Costs of pair programming •  Overhead in total hours • 

    Usual guess? •  x2, or 100% •  50 % initial overhead while the pair syncs up •  About 15 % overhead on the long run November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  97. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    WAIT!
  98. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Only 15 % total overhead?
  99. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    With TWO devs?
  100. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    No way!
  101. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    That would mean...?!?
  102. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Yes! It‘s also faster!
  103. •  Task: 8h •  Together: x1.15 à 9.2h •  Together:

    9.2h / 2 à 4.6 h •  Half a day + half an hour •  Task: 8h •  Alone: x1 à 8h •  Alone: 8h / 1 à 8h •  One full day Let‘s do the math Single Developer Pair November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  104. Gains of pair programming •  Faster time-to-market •  About 15

    % less defects •  Since costs to fix a defect later is higher than instant fixing that alone saves more than pair programming costs •  About 20 % less lines of code •  Better architecture •  Distributed knowledge •  Higher motivation •  Less distraction November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  105. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance: Unit Tests
  106. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    BUT! Expensive!
  107. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Well, a bit. Not that much (or: It depends)
  108. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    But it works http://blog.jphpsf.com/2012/09/30/OMG-test-driven-development-actually-works http://www.typemock.com/blog/2009/03/05/the-cost-of-test-driven-development
  109. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    ONLY!
  110. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    with Discipline
  111. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    and ‚Tests first‘ attitude
  112. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Tests after = tests never
  113. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Pay your insurance up front
  114. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    „Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team.“ Source: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
  115. Let‘s look at some figures •  First blog post: • 

    Full TDD (test first) for everything •  50% less defects - after 2 years •  No mention on costs, though •  Second link (study from IBM & MS) •  Costs: Time only. 15% to 35% more •  Gains: Bug ratio went down to 61% (and one product down to 9%!) November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  116. Source: „Benefit from unit testing in the real world“ November

    2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk Source: http://blog.jphpsf.com/2012/09/30/OMG-test-driven-development-actually-works
  117. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    BTW:
  118. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Want numbers?
  119. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Your tracking has them
  120. Problems with TDD •  Existing code is usually not testable

    •  Code is only written testable if tests are there upfront •  New features within existing code are hard to cover with TDD •  Writing tests is not easy and fast to learn •  especially when there‘s no TDD culture and mentors around November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  121. First easy steps to tests •  Write new code with

    TDD •  Start with simple features to get used to it •  If you access not-tested infrastructure, wrap it with something mockable that just passes through in production •  Write tests for existing code only •  when you need to do major refactorings •  when you fix a bug and that code is already testable •  or almost, with little work November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  122. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    15:30 – 16:45 Unit Tests Bernd Ua Ballsaal
  123. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance: Productivity
  124. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Warning: Expensive
  125. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Give
  126. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    your developers
  127. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    the best tools
  128. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    you can buy
  129. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    for money.
  130. Examples •  CodeRush •  Jetbrains Resharper •  Redgate SQL Toolbelt

    November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  131. Motivation •  Hacking – Nights •  Coachings •  Courses • 

    Documentation November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  132. Some sources •  „Clean Code“ by Robert C. Martin • 

    Mentions: •  http://alistair.cockburn.us/Costs+and+benefits+of+pair +programming •  http://blog.jphpsf.com/2012/09/30/OMG-test-driven- development-actually-works •  http://www.typemock.com/blog/2009/03/05/the-cost-of-test- driven-development November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk