Errors

Foreword

Introduction

1. 1960’s Forbidden Mention of Errors
2. We make errors quite regularly
3. 1960’s Cost of errors
4. “Trivial” errors can have great consequences
5. Back to 1960 again
6. Errors can escape detection for years
7. How was it tested in 1960
8. Sometimes the error is creating a program at all.
9. The full process, 1960
10. We must not confuse cost and value.
11. Coding is not the end, even in 1960
12. Programs can become erroneous without changing a bit.
13. We keep learning, but is it enough?
14. Testing for errors grows more difficult every year.

Part 1. How Do We Think About Errors?

1. 1.1 Errors in Reasoning About Errors
2. Errors are not a moral issue
3. Quality is not the same thing as absence of errors.
4. 1.2 Errors in Interpretation
5. Who are the best and the worst programmers?
6. Which is the good quality release?
7. Why is someone working late?
8. Why is the software late?
9. Which process is eliminating problems?
10. Who knows what’s right and wrong?
11. What happens to control when interpretations are backwards?
12. The Controller Fallacy
13. 1.3 The Semantics of Error
14. Names can influence the perceived severity of errors.
15. Faults and failures
16. Terms for System Trouble
17. Keeping track of faults
18. “Fault” does not imply blame
19. 1.4 Selection Fallacies About Errors
20. Completed vs. terminated projects
21. Early vs. late users
22. “He’s just like me.”
23. Three questions to prevent selection fallacies
24. 1.5 Who Decides If It’s an Error?
25. Who thinks the customer is wrong?
26. What did the consultant do?
27. What can be done when there’s no agreement?
28. Can you believe the tests and the testers?
29. Who can we believe?
30. So, what is an error?
31. 1.6. The Quest for Perfection
32. How the belief in perfection leads to error
33. What are survival rules?
34. How can meta-rules prevent change?
35. Can rules be transformed into more useful guides?
36. What’s the first step to better effectiveness?

Part 2. What Do Errors Cost?

1. 2.1 Some Very Expensive Software Errors
2. Why Concentrate on Failure?
3. What Do Failures Cost?
4. 2.2 The Universal Pattern of Costly Errors
5. What’s the pattern?
6. The universal pattern of management coping with a large loss
7. The First Rule of Failure Prevention
8. 2.3 Measuring Cost and Value
9. Mistaking cost for value
10. What is value?
11. Perceived value
12. Collapse of value
13. The Second Law of Thermodynamics
14. The First Law of Human Nature
15. To know the cost of an error, we must measure quality
16. Standards can be another secondary requirement
17. A caution about measuring value
18. 2.4. Mistakes that Win
19. Profit from your errors
20. Alexander Fleming’s Discovery of Penicillin
21. Henri Becquerel’s Discovery of Radioactivity
22. Errors are worthless, unless …

Part 3. Where Do Errors Come From?

1. 3.1 The Art of Bugging: or Where Do Bugs Come From
2. 3.2 Eight Fs of Software Failure
3. The Second Rule of Failure Prevention
4. Learning from others’ mistakes
5. Frailty
6. Folly
7. Fatuousness
8. Fun
9. Fraud
10. Fanaticism
11. Failure (of Hardware)
12. Fate
13. What’s Next?
14. 3.3 Code Is Not the Biggest Problem
15. Assuming Fixed Requirements
16. Error in English
17. My favorite error
18. What was the bug?
19. What I learned from my error
20. References
21. 3.4 Error-Prone Language
22. Heteronynms
23. Heteronyms in software
24. Hetero-sentences
25. Left ambiguity
26. Ambiguity in programs
27. Central ambiguity
28. 3.5 Predicting the Number of Errors
29. A long-term experiment
30. The history of error reporting
31. Predicting error categories
32. Assumptions underlying the method
33. Application to software errors
34. Are we ready to ship the app?
35. 3.6 Cautions in Predicting the Number of Errors
36. Using Beta-Test Results
37. Fudging for non-independence
38. Other applications
39. 3.7 It Shouldn’t Even Be Done
40. Zombie projects
41. Euthanasia reviews

Part 4. How Do We Get Rid of Errors?

1. 4.1 Finding and Fixing Errors
2. Detection
3. Location
4. Resolution
5. Prevention
6. Distribution
7. 4.2 Prevent Testing From Growing More Difficult
8. Why is the situation growing worse?
9. Why isn’t bigger actually cheaper?
10. Keep systems as small as possible.
11. Keep your model of “system” expansive.
12. Build incrementally in isolated components with clear interfaces.
13. Build the most significant functions first.
14. Reduce the number of faults going in.
15. Don’t underestimate the complexity of old, patched-up code.
16. Keep your tools sharp.
17. Encourage these matters to be discussed, as well as measured.
18. Adjust process data as current experience indicates.
19. Beware of using early returns as indicators of later results.
20. Don’t think about testers as “the bad guys who prevent delivery.”
21. 4.3 Especially Difficult Errors
22. Hail Columbia!
23. On the Beach
24. Sexism? Bigotry?
25. The disappearing act
26. What makes errors especially difficult?
27. 4.4. Learn From Errors
28. Three Lessons from a Thirty-Year Error
29. A learning paradox
30. Other ways to learn
31. 4.5 Always Be Second
32. Does first come first?
33. Where do new ideas come from?
34. 4.6 Fix Your Organization
35. A desperate letter
36. 4.7 If You Can’t Fix It, Feature It
37. Where did that feature come from?
38. Develop incrementally from the top down
39. Features Can Become Failures

Part 5. How Do We Prevent Errors?

1. 5.1 Keep It Simple
2. How we build makes a difference.
3. Optimizing encourages errors.
4. Fancy can be a synonym for complex.
5. Use the Square Law of Computation.
6. A stitch in time saves nine.
7. 5.2 Throw It Away
8. Reuse or reject?
9. Things change
10. Pay the true cost of retention
11. 5.3 Go Slow, Go Fast
12. Beware of the Quick Fix
13. Rapid prototyping?
14. Lessons of history
15. Hurry
16. 5.4 Test as You Build
17. Reuse well-tested code
18. Test all your ideas
19. Start with the biggest risks
20. Perform a Hudson’s Bay Start
21. Prototype
22. Deliver before you deliver
23. 5.5. Improve Communication
24. Interface treaties
25. Enforcement
26. What if they won’t sign?
27. 5.6 Rethink Your Organization
28. What’s needed for a normal project?
29. What every organization needs
30. Start with one little change
31. 5.7 Master Your Fear
32. Rhubarb Cakes for the Queen of the Forest
33. The lesson

Part 6. Living With Errors

1. 6.1 The Humpty Dumpty world
2. 6.2 The First Law of Error Defense
3. 6.3 The Second Law of Error Defense
4. 6.4 The Third Law of Error Defense
5. 6.5 The Fourth Law of Error Defense
6. 6.6 The Fifth Law of Error Defense
7. 6.7 The Sixth Law of Error Defense
8. 6.8 The Seventh Law of Error Defense
9. 6.9 The Eighth Law of Error Defense
10. The End, for now

Appendix. Error Messages

1. Message Irrelevant
2. Message Contradictory
3. Message Not Clear
4. Clear but Misdirects
5. Message Not Explicit
6. Message Offensive
7. No Message
8. Some Conclusions