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

Presentation given in the Lausanne Barcamp, March 2008.

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