Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKON 16: Software Quality 101

EKON 16: Software Quality 101

The slides for the Software Quality talk at EKON 16.

Sebastian Gingter

November 06, 2012
Tweet

More Decks by Sebastian Gingter

Other Decks in Technology

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

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

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

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

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

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

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

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

    Traceability Discipline Productivity & Diligence
  10. 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
  11. 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
  12. 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
  13. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Traceability Discipline Productivity & Diligence
  14. „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
  15. 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
  16. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

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

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

    Small ‚but‘: Requires good SCM tooling
  19. Benefits of training •  Better developers •  Less errors • 

    Higher motivation November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  20. 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
  21. Tooling for .NET •  FxCop •  StyleCop November 2012 -

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

    16 Sebastian P.R. Gingter - @PhoenixHawk
  23. Amusement: Joe O‘Brien & Jim Weirich: Ruby code review November

    2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  24. 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
  25. 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
  26. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Hell, NO! Source: http://alistair.cockburn.us/Costs+and+benefits+of+pair+programming
  27. 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
  28. •  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
  29. 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
  30. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    Well, a bit. Not that much (or: It depends)
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk

    15:30 – 16:45 Unit Tests Bernd Ua Ballsaal
  38. Examples •  CodeRush •  Jetbrains Resharper •  Redgate SQL Toolbelt

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

    Documentation November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
  40. 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