EKON 18: Softwarequalität

EKON 18: Softwarequalität

My slides for the EKON 18 (2014) talk about software quality.

Ebeb5d8fd081058ba8df73d378bf83d7?s=128

Sebastian P.R. Gingter

November 03, 2014
Tweet

Transcript

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

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

    Why Quality?
  3. November 2014 - EKON 18 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance
  4. November 2014 - EKON 18 Sebastian P.R. Gingter - @PhoenixHawk

    Insurance always costs
  5. November 2014 - EKON 18 Sebastian P.R. Gingter - @PhoenixHawk

    Defects always cost
  6. Sebastian P.R. Gingter - @PhoenixHawk „Software quality measures always are

    a trade-off between insurance and defect costs.“ November 2014 - EKON 18
  7. Sebastian P.R. Gingter - @PhoenixHawk Quality costs money November 2014

    - EKON 18
  8. Sebastian P.R. Gingter - @PhoenixHawk Time = money November 2014

    - EKON 18
  9. Sebastian P.R. Gingter - @PhoenixHawk Focus: little overhead for good

    gain November 2014 - EKON 18
  10. Sebastian P.R. Gingter - @PhoenixHawk Basic requirements November 2014 -

    EKON 18
  11. Sebastian P.R. Gingter - @PhoenixHawk Source Control November 2014 -

    EKON 18
  12. Sebastian P.R. Gingter - @PhoenixHawk CVS / VSS November 2014

    - EKON 18
  13. Sebastian P.R. Gingter - @PhoenixHawk SVN / Git / Hg

    / TFS November 2014 - EKON 18
  14. Sebastian P.R. Gingter - @PhoenixHawk Bug tracking November 2014 -

    EKON 18
  15. Sebastian P.R. Gingter - @PhoenixHawk Bug & Feature tracking November

    2014 - EKON 18
  16. Sebastian P.R. Gingter - @PhoenixHawk EXCEL November 2014 - EKON

    18
  17. Sebastian P.R. Gingter - @PhoenixHawk OnTime, YouTrack, Mantis, Jira, Bugzilla,

    Roundup, Redmine, FogBugz, you name it... November 2014 - EKON 18
  18. Sebastian P.R. Gingter - @PhoenixHawk Ideally: Integrated with SCM November

    2014 - EKON 18
  19. Sebastian P.R. Gingter - @PhoenixHawk Ideally: Integrated with time recording

    November 2014 - EKON 18
  20. Sebastian P.R. Gingter - @PhoenixHawk Bug: Description Repro Reason Solution

    Time spent November 2014 - EKON 18
  21. Sebastian P.R. Gingter - @PhoenixHawk Feature: Precise description Documentation Approach

    Time spent Description of tests November 2014 - EKON 18
  22. Sebastian P.R. Gingter - @PhoenixHawk Checkins only with Task #ID

    November 2014 - EKON 18
  23. Sebastian P.R. Gingter - @PhoenixHawk Continous integration November 2014 -

    EKON 18
  24. Sebastian P.R. Gingter - @PhoenixHawk Ideally: Integrated with SCM &

    tracking November 2014 - EKON 18
  25. Sebastian P.R. Gingter - @PhoenixHawk Build every single checkin November

    2014 - EKON 18
  26. Sebastian P.R. Gingter - @PhoenixHawk Enables you to test every

    single checkin November 2014 - EKON 18
  27. Sebastian P.R. Gingter - @PhoenixHawk WHY ? November 2014 -

    EKON 18
  28. Sebastian P.R. Gingter - @PhoenixHawk You want control November 2014

    - EKON 18
  29. Sebastian P.R. Gingter - @PhoenixHawk Traceability November 2014 - EKON

    18
  30. Sebastian P.R. Gingter - @PhoenixHawk Discipline November 2014 - EKON

    18
  31. Sebastian P.R. Gingter - @PhoenixHawk Productivity & Diligence November 2014

    - EKON 18
  32. Sebastian P.R. Gingter - @PhoenixHawk Traceability Discipline Productivity & Diligence

    November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  34. Why continuous integration? •  Fail fast as insurance •  Fastest

    possible feedback on •  THAT something broke •  and from the logs also WHAT broke Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  36. Sebastian P.R. Gingter - @PhoenixHawk SCM Tracking CI November 2014

    - EKON 18
  37. Sebastian P.R. Gingter - @PhoenixHawk Traceability Discipline Productivity & Diligence

    November 2014 - EKON 18
  38. Sebastian P.R. Gingter - @PhoenixHawk One more thing: November 2014

    - EKON 18
  39. Sebastian P.R. Gingter - @PhoenixHawk Clean code November 2014 -

    EKON 18
  40. Sebastian P.R. Gingter - @PhoenixHawk Not the movement November 2014

    - EKON 18
  41. Sebastian P.R. Gingter - @PhoenixHawk Simply ‚clean‘ code November 2014

    - EKON 18
  42. Sebastian P.R. Gingter - @PhoenixHawk Only ‚but‘: Requires discipline November

    2014 - EKON 18
  43. Sebastian P.R. Gingter - @PhoenixHawk Easy & cheap measures November

    2014 - EKON 18
  44. Sebastian P.R. Gingter - @PhoenixHawk Focus development process on quality

    November 2014 - EKON 18
  45. Sebastian P.R. Gingter - @PhoenixHawk Don‘t do post-QA November 2014

    - EKON 18
  46. Sebastian P.R. Gingter - @PhoenixHawk Automate November 2014 - EKON

    18
  47. Sebastian P.R. Gingter - @PhoenixHawk Automate recurring tasks November 2014

    - EKON 18
  48. Sebastian P.R. Gingter - @PhoenixHawk Automate error-prone tasks November 2014

    - EKON 18
  49. Sebastian P.R. Gingter - @PhoenixHawk Automate tedious tasks November 2014

    - EKON 18
  50. Sebastian P.R. Gingter - @PhoenixHawk Change tools only where required

    November 2014 - EKON 18
  51. Sebastian P.R. Gingter - @PhoenixHawk Process November 2014 - EKON

    18
  52. Sebastian P.R. Gingter - @PhoenixHawk Eliminate possible error sources November

    2014 - EKON 18
  53. Sebastian P.R. Gingter - @PhoenixHawk Introduce insurances November 2014 -

    EKON 18
  54. Sebastian P.R. Gingter - @PhoenixHawk Insurance: „stable branches“ November 2014

    - EKON 18
  55. Sebastian P.R. Gingter - @PhoenixHawk Design your branching model November

    2014 - EKON 18
  56. „stable branches“ •  Ensure that you are able •  to

    release a •  stable version •  at every given moment in time Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  58. Sebastian P.R. Gingter - @PhoenixHawk Prevents ‚half baked‘ features November

    2014 - EKON 18
  59. Sebastian P.R. Gingter - @PhoenixHawk Prevents blocked hotfix releases November

    2014 - EKON 18
  60. Sebastian P.R. Gingter - @PhoenixHawk Prevents accidentally releasing crap November

    2014 - EKON 18
  61. Sebastian P.R. Gingter - @PhoenixHawk Enables delaying release of unfinished

    stuff November 2014 - EKON 18
  62. Sebastian P.R. Gingter - @PhoenixHawk Only little overhead in branching

    / merging November 2014 - EKON 18
  63. Sebastian P.R. Gingter - @PhoenixHawk Small ‚but‘: Requires good SCM

    tooling November 2014 - EKON 18
  64. Sebastian P.R. Gingter - @PhoenixHawk Insurance: Training November 2014 -

    EKON 18
  65. Sebastian P.R. Gingter - @PhoenixHawk Give Devs training time November

    2014 - EKON 18
  66. Sebastian P.R. Gingter - @PhoenixHawk not too much November 2014

    - EKON 18
  67. Sebastian P.R. Gingter - @PhoenixHawk distracting November 2014 - EKON

    18
  68. Sebastian P.R. Gingter - @PhoenixHawk Time = money November 2014

    - EKON 18
  69. Sebastian P.R. Gingter - @PhoenixHawk Alternative: Give access to courses

    November 2014 - EKON 18
  70. Sebastian P.R. Gingter - @PhoenixHawk Most important November 2014 -

    EKON 18
  71. Sebastian P.R. Gingter - @PhoenixHawk Allow opportunities to fail November

    2014 - EKON 18
  72. Sebastian P.R. Gingter - @PhoenixHawk learning by failure November 2014

    - EKON 18
  73. Sebastian P.R. Gingter - @PhoenixHawk Hacking nights, couch coding November

    2014 - EKON 18
  74. Sebastian P.R. Gingter - @PhoenixHawk In spare time November 2014

    - EKON 18
  75. Benefits of training •  Better developers •  Less errors • 

    Higher motivation Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  76. Sebastian P.R. Gingter - @PhoenixHawk Insurance: Review November 2014 -

    EKON 18
  77. Sebastian P.R. Gingter - @PhoenixHawk Caution: problematic November 2014 -

    EKON 18
  78. Sebastian P.R. Gingter - @PhoenixHawk Intuitive: Review before reintegrate November

    2014 - EKON 18
  79. Sebastian P.R. Gingter - @PhoenixHawk Styleguide correctly used? November 2014

    - EKON 18
  80. Sebastian P.R. Gingter - @PhoenixHawk There‘s an app for that!

    November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  82. Tooling for .NET •  FxCop •  StyleCop Sebastian P.R. Gingter

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

    @PhoenixHawk November 2014 - EKON 18
  84. Shoot the Developer! Sebastian P.R. Gingter - @PhoenixHawk November 2014

    - EKON 18
  85. Amusement: Joe O‘Brien & Jim Weirich: Ruby code review Sebastian

    P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  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}“ Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  87. Sebastian P.R. Gingter - @PhoenixHawk Don‘t do them November 2014

    - EKON 18
  88. Sebastian P.R. Gingter - @PhoenixHawk WTF? November 2014 - EKON

    18
  89. Sebastian P.R. Gingter - @PhoenixHawk Yes: Don‘t do them! November

    2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  91. Sebastian P.R. Gingter - @PhoenixHawk So, what else, if not

    code reviews? November 2014 - EKON 18
  92. Sebastian P.R. Gingter - @PhoenixHawk Insurance November 2014 - EKON

    18
  93. Pair programming Sebastian P.R. Gingter - @PhoenixHawk November 2014 -

    EKON 18
  94. Sebastian P.R. Gingter - @PhoenixHawk But!!! Expensive!!! November 2014 -

    EKON 18
  95. Sebastian P.R. Gingter - @PhoenixHawk Hell, NO! Source: http://alistair.cockburn.us/Costs+and+benefits+of+pair+programming November

    2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  97. Sebastian P.R. Gingter - @PhoenixHawk WAIT! November 2014 - EKON

    18
  98. Sebastian P.R. Gingter - @PhoenixHawk Only 15 % total overhead?

    November 2014 - EKON 18
  99. Sebastian P.R. Gingter - @PhoenixHawk With TWO devs? November 2014

    - EKON 18
  100. Sebastian P.R. Gingter - @PhoenixHawk No way! November 2014 -

    EKON 18
  101. Sebastian P.R. Gingter - @PhoenixHawk That would mean...?!? November 2014

    - EKON 18
  102. Sebastian P.R. Gingter - @PhoenixHawk Yes! It‘s also faster! November

    2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  105. Sebastian P.R. Gingter - @PhoenixHawk Insurance: Unit Tests November 2014

    - EKON 18
  106. Sebastian P.R. Gingter - @PhoenixHawk BUT! Expensive! November 2014 -

    EKON 18
  107. Sebastian P.R. Gingter - @PhoenixHawk Well, a bit. Not that

    much (or: It depends) November 2014 - EKON 18
  108. 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

    November 2014 - EKON 18
  109. Sebastian P.R. Gingter - @PhoenixHawk ONLY! November 2014 - EKON

    18
  110. Sebastian P.R. Gingter - @PhoenixHawk with Discipline November 2014 -

    EKON 18
  111. Sebastian P.R. Gingter - @PhoenixHawk and ‚Tests first‘ attitude November

    2014 - EKON 18
  112. Sebastian P.R. Gingter - @PhoenixHawk Tests after = tests never

    November 2014 - EKON 18
  113. Sebastian P.R. Gingter - @PhoenixHawk Pay your insurance up front

    November 2014 - EKON 18
  114. 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 November 2014 - EKON 18
  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%!) Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  116. Source: „Benefit from unit testing in the real world“ Sebastian

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

    18
  118. Sebastian P.R. Gingter - @PhoenixHawk Want numbers? November 2014 -

    EKON 18
  119. Sebastian P.R. Gingter - @PhoenixHawk Your tracking has them November

    2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  122. Sebastian P.R. Gingter - @PhoenixHawk Insurance: Productivity November 2014 -

    EKON 18
  123. Sebastian P.R. Gingter - @PhoenixHawk Warning: Expensive November 2014 -

    EKON 18
  124. Sebastian P.R. Gingter - @PhoenixHawk Give November 2014 - EKON

    18
  125. Sebastian P.R. Gingter - @PhoenixHawk your developers November 2014 -

    EKON 18
  126. Sebastian P.R. Gingter - @PhoenixHawk the best tools November 2014

    - EKON 18
  127. Sebastian P.R. Gingter - @PhoenixHawk you can buy November 2014

    - EKON 18
  128. Sebastian P.R. Gingter - @PhoenixHawk for money. November 2014 -

    EKON 18
  129. Examples •  CodeRush •  Jetbrains Resharper •  Redgate SQL Toolbelt

    Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  130. Motivation •  Hacking – Nights •  Coachings •  Courses • 

    Documentation Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  131. 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 Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  132. Sebastian P.R. Gingter - @PhoenixHawk Vielen Dank Fragen? Antworten! November

    2014 - EKON 18