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. 1.

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

    November 2014 Slides: https://speakerdeck.com/u/phoenixhawk
  2. 6.

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

    a trade-off between insurance and defect costs.“ November 2014 - EKON 18
  3. 13.
  4. 17.

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

    Roundup, Redmine, FogBugz, you name it... November 2014 - EKON 18
  5. 21.
  6. 26.
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 75.

    Benefits of training •  Better developers •  Less errors • 

    Higher motivation Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  13. 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
  14. 85.

    Amusement: Joe O‘Brien & Jim Weirich: Ruby code review Sebastian

    P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  15. 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
  16. 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
  17. 91.

    Sebastian P.R. Gingter - @PhoenixHawk So, what else, if not

    code reviews? November 2014 - EKON 18
  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
  19. 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
  20. 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
  21. 107.

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

    much (or: It depends) November 2014 - EKON 18
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 129.

    Examples •  CodeRush •  Jetbrains Resharper •  Redgate SQL Toolbelt

    Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  28. 130.

    Motivation •  Hacking – Nights •  Coachings •  Courses • 

    Documentation Sebastian P.R. Gingter - @PhoenixHawk November 2014 - EKON 18
  29. 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