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”?

  2. A grumpy developer’s perspective

  3. And 4 simple steps

  4. Adrian Kosmaczewski

  5. Software developer

  6. since 1996

  7. None
  8. None
  9. None
  10. None
  11. None
  12. None
  13. None
  14. None
  15. None
  16. None
  17. Houston,

  18. “Our society depends on software”

  19. Bjarne Stroustrup

  20. None
  21. Yes, but:

  22. Software Sucks

  23. (some of it)

  24. (mine does)

  25. (sometimes)

  26. None
  27. None
  28. 500M

  29. Integer overflow

  30. Nobody died

  31. Therac-25

  32. None
  33. 6 people died

  34. Overexposed to radiation

  35. 1982 Soviet Gas Pipeline Explosion

  36. Largest non-atomic explosion of history

  37. Bug injected by CIA

  38. 1988 Morris worm

  39. First network worm

  40. Buffer overflow

  41. 1988 Russian “Phobos” Probe in Mars

  42. Bad thruster deactivation

  43. 1992 London Ambulance System

  44. No official statistics about casualties

  45. 1993 Pentium bug

  46. *giggle*

  47. 1998 USS Yorktown

  48. Ship lost in the ocean

  49. Divide by zero error

  50. 1999 Mars Climate Orbiter

  51. Miles or kilometers?

  52. 1999 Mars Polar Lander

  53. Vibrations? Cut the engines!

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

  55. 2000 National Cancer Institute, Panama

  56. 8 patients die

  57. 20 other overdosed

  58. Doctors indicted for murder

  59. 2003 USA Blackout

  60. Race condition

  61. 2006 Mars Global Surveyor

  62. Motor dead? Yes? No!

  63. Yeah!

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

  65. Status 1994 2006 Success 16% 35% Challenged 53% 46% Failed

    31% 19% Source: http://tinyurl.com/yodqnw
  66. None
  67. What about us?

  68. No space missions

  69. Smaller projects

  70. Similar problems

  71. Software is expensive

  72. ISO Certifications are worthless

  73. CMMI certifications are (less) worthless

  74. Software Quality theory is boring

  75. None
  76. Well, almost

  77. None
  78. None
  79. None
  80. None
  81. None
  82. None
  83. None
  84. Avoid being on The Daily WTF

  85. 4 steps

  86. None
  87. 1. Pass the Joel Test 2. Avoid Open Spaces 3.

    At least write unit tests 4. Communicate
  88. None
  89. 1 The Joel Test http://tinyurl.com/1s8w

  90. None
  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?
  92. How much is your score?

  93. Be honest! :)

  94. None
  95. 2 Avoid open spaces

  96. Cheaper?

  97. None
  98. None
  99. None
  100. None
  101. None
  102. •Noise •Interruptions •Phones •iPods •Lack of privacy Why not?

  103. Ever heard about “Peopleware”?

  104. None
  105. Buy it and read it

  106. “Flow”

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

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

  109. Turnover is your enemy # 1

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

    run
  111. None
  112. 3 At least, write unit tests

  113. You’ll thank me

  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
  115. Why?

  116. Easy

  117. Free

  118. Refactoring

  119. Documentation

  120. Usage examples

  121. Maintenance

  122. Architecture

  123. API Design

  124. Performance

  125. Good karma

  126. How much testing?

  127. Enough

  128. Don’t become fanatic

  129. (at least) One for every bug

  130. Avoid regressions

  131. Run them at every build

  132. Script that build!

  133. None
  134. 4 Communicate

  135. Wiki

  136. Blog

  137. Trac

  138. Visual Studio Team System

  139. (yuck!)

  140. Bugzilla

  141. Meetings

  142. Don’t make them regular

  143. Make them ad-hoc

  144. Prefer code reviews

  145. Client on board

  146. Not always possible!

  147. But extremely useful

  148. Conclusion

  149. 1. Pass the Joel Test 2. Avoid Open Spaces 3.

    At least write unit tests 4. Communicate
  150. Thanks!

  151. Questions?