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

What happened to those nice words, “Software Quality”?

What happened to those nice words, “Software Quality”?

Presentation given in the Lausanne Barcamp, March 2008.

Adrian Kosmaczewski
PRO

March 08, 2008
Tweet

More Decks by Adrian Kosmaczewski

Other Decks in Technology

Transcript

  1. What happened to
    those nice words,
    “Software Quality”?

    View Slide

  2. A grumpy
    developer’s
    perspective

    View Slide

  3. And 4 simple steps

    View Slide

  4. Adrian
    Kosmaczewski

    View Slide

  5. Software developer

    View Slide

  6. since 1996

    View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  14. View Slide

  15. View Slide

  16. View Slide

  17. Houston,

    View Slide

  18. “Our society
    depends on
    software”

    View Slide

  19. Bjarne Stroustrup

    View Slide

  20. View Slide

  21. Yes, but:

    View Slide

  22. Software Sucks

    View Slide

  23. (some of it)

    View Slide

  24. (mine does)

    View Slide

  25. (sometimes)

    View Slide

  26. View Slide

  27. View Slide

  28. 500M

    View Slide

  29. Integer overflow

    View Slide

  30. Nobody died

    View Slide

  31. Therac-25

    View Slide

  32. View Slide

  33. 6 people died

    View Slide

  34. Overexposed to
    radiation

    View Slide

  35. 1982 Soviet Gas
    Pipeline Explosion

    View Slide

  36. Largest non-atomic
    explosion of history

    View Slide

  37. Bug injected by CIA

    View Slide

  38. 1988 Morris worm

    View Slide

  39. First network worm

    View Slide

  40. Buffer overflow

    View Slide

  41. 1988 Russian
    “Phobos” Probe in
    Mars

    View Slide

  42. Bad thruster
    deactivation

    View Slide

  43. 1992 London
    Ambulance System

    View Slide

  44. No official statistics
    about casualties

    View Slide

  45. 1993 Pentium bug

    View Slide

  46. *giggle*

    View Slide

  47. 1998 USS Yorktown

    View Slide

  48. Ship lost in the
    ocean

    View Slide

  49. Divide by zero error

    View Slide

  50. 1999 Mars Climate
    Orbiter

    View Slide

  51. Miles or
    kilometers?

    View Slide

  52. 1999 Mars Polar
    Lander

    View Slide

  53. Vibrations? Cut the
    engines!

    View Slide

  54. Geez, it was the
    atmosphere... not
    the ground!

    View Slide

  55. 2000 National
    Cancer Institute,
    Panama

    View Slide

  56. 8 patients die

    View Slide

  57. 20 other overdosed

    View Slide

  58. Doctors indicted for
    murder

    View Slide

  59. 2003 USA Blackout

    View Slide

  60. Race condition

    View Slide

  61. 2006 Mars Global
    Surveyor

    View Slide

  62. Motor dead? Yes?
    No!

    View Slide

  63. Yeah!

    View Slide

  64. Ever heard about
    the CHAOS report?
    http://www.standishgroup.com/

    View Slide

  65. Status 1994 2006
    Success 16% 35%
    Challenged 53% 46%
    Failed 31% 19%
    Source: http://tinyurl.com/yodqnw

    View Slide

  66. View Slide

  67. What about us?

    View Slide

  68. No space missions

    View Slide

  69. Smaller projects

    View Slide

  70. Similar problems

    View Slide

  71. Software is
    expensive

    View Slide

  72. ISO Certifications
    are worthless

    View Slide

  73. CMMI certifications
    are (less) worthless

    View Slide

  74. Software Quality
    theory is boring

    View Slide

  75. View Slide

  76. Well, almost

    View Slide

  77. View Slide

  78. View Slide

  79. View Slide

  80. View Slide

  81. View Slide

  82. View Slide

  83. View Slide

  84. Avoid being on
    The Daily WTF

    View Slide

  85. 4 steps

    View Slide

  86. View Slide

  87. 1. Pass the Joel Test
    2. Avoid Open Spaces
    3. At least write unit tests
    4. Communicate

    View Slide

  88. View Slide

  89. 1
    The Joel Test
    http://tinyurl.com/1s8w

    View Slide

  90. View Slide

  91. The Joel Test
    1. Do you use source control?
    2. Can you make a build in one step?
    3. Do you make daily builds?
    4. Do you have a bug database?
    5. Do you fix bugs before writing new code?
    6. Do you have an up-to-date schedule?
    7. Do you have a spec?
    8. Do programmers have quiet working conditions?
    9. Do you use the best tools money can buy?
    10. Do you have testers?
    11. Do new candidates write code during their interview?
    12. Do you do hallway usability testing?

    View Slide

  92. How much is your
    score?

    View Slide

  93. Be honest! :)

    View Slide

  94. View Slide

  95. 2
    Avoid open spaces

    View Slide

  96. Cheaper?

    View Slide

  97. View Slide

  98. View Slide

  99. View Slide

  100. View Slide

  101. View Slide

  102. •Noise
    •Interruptions
    •Phones
    •iPods
    •Lack of privacy
    Why not?

    View Slide

  103. Ever heard about
    “Peopleware”?

    View Slide

  104. View Slide

  105. Buy it and
    read it

    View Slide

  106. “Flow”

    View Slide

  107. http://www.ndesign-studio.com/images/portfolio/graphic/flow-1.jpg

    View Slide

  108. Consequences
    •Low quality
    •Late delivery
    •Burnout
    •Turnover

    View Slide

  109. Turnover is your
    enemy # 1

    View Slide

  110. Cheaper in the
    short term means
    expensive in the
    long run

    View Slide

  111. View Slide

  112. 3
    At least,
    write unit tests

    View Slide

  113. You’ll thank me

    View Slide

  114. •JUnit
    •NUnit
    •PyUnit
    •Unit::Test (Ruby)
    •RSpec (Ruby)
    •CppUnit (C++)
    •Boost Test (C++)
    •Autounit (C)
    •JSUnit (JavaScript)
    •WOTest (ObjC)
    •PHPUnit
    •FoxUnit (FoxPro)
    •Selenium
    •lisp-unit
    •DUnit
    •SchemeUnit

    View Slide

  115. Why?

    View Slide

  116. Easy

    View Slide

  117. Free

    View Slide

  118. Refactoring

    View Slide

  119. Documentation

    View Slide

  120. Usage examples

    View Slide

  121. Maintenance

    View Slide

  122. Architecture

    View Slide

  123. API Design

    View Slide

  124. Performance

    View Slide

  125. Good karma

    View Slide

  126. How much testing?

    View Slide

  127. Enough

    View Slide

  128. Don’t become
    fanatic

    View Slide

  129. (at least)
    One for every bug

    View Slide

  130. Avoid regressions

    View Slide

  131. Run them at every
    build

    View Slide

  132. Script that build!

    View Slide

  133. View Slide

  134. 4
    Communicate

    View Slide

  135. Wiki

    View Slide

  136. Blog

    View Slide

  137. Trac

    View Slide

  138. Visual Studio
    Team System

    View Slide

  139. (yuck!)

    View Slide

  140. Bugzilla

    View Slide

  141. Meetings

    View Slide

  142. Don’t make them
    regular

    View Slide

  143. Make them ad-hoc

    View Slide

  144. Prefer code reviews

    View Slide

  145. Client on board

    View Slide

  146. Not always
    possible!

    View Slide

  147. But extremely
    useful

    View Slide

  148. Conclusion

    View Slide

  149. 1. Pass the Joel Test
    2. Avoid Open Spaces
    3. At least write unit tests
    4. Communicate

    View Slide

  150. Thanks!

    View Slide

  151. Questions?

    View Slide