Leanpub The Leanpub Logo is a Registered Trademark
Errors
Errors
$9.99
Minimum price
$9.99
Suggested price
  • 171

    Pages

  • English

  • PDF

  • EPUB

  • MOBI

  • APP

Errors

Last updated on 2017-08-12

About the Book

I'm placing this complete but unpolished version of Errors up for sale so my readers can provide feedback to make it better. Every purchaser will have access to free updates and revisions as they are made. I can be reached at jerryweinberg@comcast.net

Introduction

Part 1. How Do We Think About Errors?

1.1 Errors in Reasoning About Errors

1.2 Errors in Interpretation

1.3 The Semantics of Error.pages

1.4 Selection Fallacies about Errors.pages

1.6 The Quest for Perfection

1.5 Who Decides If It's an Error?

Part 2. What Do Errors Cost?

2.1 Some Very Expensive Software Errors

2.2 Universal Pattern of Costly Errors

2.3 Measuring Cost and Value

2.4 Mistakes that Win.pages

Part 3. Where Do Errors Come From?

3.1 The Art of Bugging

3.2 Eight Fs of Software Failure

3.3 Code is Not the Biggest Problem

3.4 Error-Prone Language

3.5 Predicting the Number of Errors

3.6. Cautions in Predicting the Number of Errors

3.7 It Shouldn't Even Be Done

Part 4. How Do We Get Rid of Errors?

4.1 Finding and Fixing Errors

4.2 Prevent Testing From Growing More Difficult

4.3 Especially Difficult Errors

4.4 Learn from Errors

4.5 Always Be Second

4.6 Fix Your Organization

4.7 If You Can't Fix It, Feature It

Part 5. How Do We Prevent Errors?

5.1 Keep It Simple

5.2 Throw It Away

5.3 Go Slow, Go Fast

5.4 Test as You Build

5.5 Improve Communication

5.6 Rethink Your Organization

5.7 Master Your Fear

Part 6. Living With Errors

6.1 The Humpty Dumpty world

6.2 The First Law of Error Defense

6.3 The Second Law of Error Defense

6.4 The Third Law of Error Defense

6.5 The Fourth Law of Error Defense

6.6 The Fifth Law of Error Defense

6.7 The Sixth Law of Error Defense

6.8 The Seventh Law of Error Defense

6.9 The Eight Law of Error Defense

About the Author

Gerald M. Weinberg
Gerald M. Weinberg

I've always been interested in helping smart people be happy and productive. To that end, I've published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. I've also written books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the nine-volume Quality Software series.

I try to incorporate my knowledge of science, engineering, and human behavior into all of my writing and consulting work (with writers, hi-tech researchers, software engineers, and people whose life-situation could require the use of a service dog). I write novels about such people, including The Aremac Project, Aremac Power, Jigglers, First Stringers, Second Stringers, The Hands of God, Freshman Murders, Where There's a Will There's a Murder, Earth's Endless Effort, and Mistress of Molecules—all about how my brilliant protagonists produce quality work and learn to be happy. My books that are not yet on Leanpub may be found as eBooks at <http://www.smashwords.com/profile/view/JerryWeinberg>; on Amazon at http://www.amazon.com/-/e/B000AP8TZ8; and at Barnes and Noble bookstore: http://tinyurl.com/4eudqk5.

Early in my career, I was the architect for the Project Mercury's space tracking network and designer of the world's first multiprogrammed operating system. I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals' Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame.

But the "award" I'm most proud of is the book, The Gift of Time (Fiona Charles, ed.) written by my student and readers for my 75th birthday. Their stories make me feel that I've been at least partially successful at helping smart people be happy.

Table of Contents

  • Foreword
  • Introduction
    •  
      • 1960’s Forbidden Mention of Errors
      • We make errors quite regularly
      • 1960’s Cost of errors
      • “Trivial” errors can have great consequences
      • Back to 1960 again
      • Errors can escape detection for years
      • How was it tested in 1960
      • Sometimes the error is creating a program at all.
      • The full process, 1960
      • We must not confuse cost and value.
      • Coding is not the end, even in 1960
      • Programs can become erroneous without changing a bit.
      • We keep learning, but is it enough?
      • Testing for errors grows more difficult every year.
  • Part 1. How Do We Think About Errors?
    • 1.1 Errors in Reasoning About Errors
      • Errors are not a moral issue
      • Quality is not the same thing as absence of errors.
    • 1.2 Errors in Interpretation
      • Who are the best and the worst programmers?
      • Which is the good quality release?
      • Why is someone working late?
      • Why is the software late?
      • Which process is eliminating problems?
      • Who knows what’s right and wrong?
      • What happens to control when interpretations are backwards?
      • The Controller Fallacy
    • 1.3 The Semantics of Error
      • Names can influence the perceived severity of errors.
      • Faults and failures
      • Terms for System Trouble
      • Keeping track of faults
      • “Fault” does not imply blame
    • 1.4 Selection Fallacies About Errors
      • Completed vs. terminated projects
      • Early vs. late users
      • “He’s just like me.”
      • Three questions to prevent selection fallacies
    • 1.5 Who Decides If It’s an Error?
      • Who thinks the customer is wrong?
      • What did the consultant do?
      • What can be done when there’s no agreement?
      • Can you believe the tests and the testers?
      • Who can we believe?
      • So, what is an error?
    • 1.6. The Quest for Perfection
      • How the belief in perfection leads to error
      • What are survival rules?
      • How can meta-rules prevent change?
      • Can rules be transformed into more useful guides?
      • What’s the first step to better effectiveness?
  • Part 2. What Do Errors Cost?
    • 2.1 Some Very Expensive Software Errors
      • Why Concentrate on Failure?
      • What Do Failures Cost?
    • 2.2 The Universal Pattern of Costly Errors
      • What’s the pattern?
      • The universal pattern of management coping with a large loss
      • The First Rule of Failure Prevention
    • 2.3 Measuring Cost and Value
      • Mistaking cost for value
      • What is value?
      • Perceived value
      • Collapse of value
      • The Second Law of Thermodynamics
      • The First Law of Human Nature
      • To know the cost of an error, we must measure quality
      • Standards can be another secondary requirement
      • A caution about measuring value
    • 2.4. Mistakes that Win
      • Profit from your errors
      • Alexander Fleming’s Discovery of Penicillin
      • Henri Becquerel’s Discovery of Radioactivity
      • Errors are worthless, unless …
  • Part 3. Where Do Errors Come From?
    • 3.1 The Art of Bugging: or Where Do Bugs Come From
    • 3.2 Eight Fs of Software Failure
      • The Second Rule of Failure Prevention
      • Learning from others’ mistakes
      • Frailty
      • Folly
      • Fatuousness
      • Fun
      • Fraud
      • Fanaticism
      • Failure (of Hardware)
      • Fate
      • What’s Next?
    • 3.3 Code Is Not the Biggest Problem
      • Assuming Fixed Requirements
      • Error in English
      • My favorite error
      • What was the bug?
      • What I learned from my error
      • References
    • 3.4 Error-Prone Language
      • Heteronynms
      • Heteronyms in software
      • Hetero-sentences
      • Left ambiguity
      • Ambiguity in programs
      • Central ambiguity
    • 3.5 Predicting the Number of Errors
      • A long-term experiment
      • The history of error reporting
      • Predicting error categories
      • Assumptions underlying the method
      • Application to software errors
      • Are we ready to ship the app?
    • 3.6 Cautions in Predicting the Number of Errors
      • Using Beta-Test Results
      • Fudging for non-independence
      • Other applications
    • 3.7 It Shouldn’t Even Be Done
      • Zombie projects
      • Euthanasia reviews
  • Part 4. How Do We Get Rid of Errors?
    • 4.1 Finding and Fixing Errors
      • Detection
      • Location
      • Resolution
      • Prevention
      • Distribution
    • 4.2 Prevent Testing From Growing More Difficult
      • Why is the situation growing worse?
      • Why isn’t bigger actually cheaper?
      • Keep systems as small as possible.
      • Keep your model of “system” expansive.
      • Build incrementally in isolated components with clear interfaces.
      • Build the most significant functions first.
      • Reduce the number of faults going in.
      • Don’t underestimate the complexity of old, patched-up code.
      • Keep your tools sharp.
      • Encourage these matters to be discussed, as well as measured.
      • Adjust process data as current experience indicates.
      • Beware of using early returns as indicators of later results.
      • Don’t think about testers as “the bad guys who prevent delivery.”
    • 4.3 Especially Difficult Errors
      • Hail Columbia!
      • On the Beach
      • Sexism? Bigotry?
      • The disappearing act
      • What makes errors especially difficult?
    • 4.4. Learn From Errors
      • Three Lessons from a Thirty-Year Error
      • A learning paradox
      • Other ways to learn
    • 4.5 Always Be Second
      • Does first come first?
      • Where do new ideas come from?
    • 4.6 Fix Your Organization
      • A desperate letter
    • 4.7 If You Can’t Fix It, Feature It
      • Where did that feature come from?
      • Develop incrementally from the top down
      • Features Can Become Failures
  • Part 5. How Do We Prevent Errors?
    • 5.1 Keep It Simple
      • How we build makes a difference.
      • Optimizing encourages errors.
      • Fancy can be a synonym for complex.
      • Use the Square Law of Computation.
      • A stitch in time saves nine.
    • 5.2 Throw It Away
      • Reuse or reject?
      • Things change
      • Pay the true cost of retention
    • 5.3 Go Slow, Go Fast
      • Beware of the Quick Fix
      • Rapid prototyping?
      • Lessons of history
      • Hurry
    • 5.4 Test as You Build
      • Reuse well-tested code
      • Test all your ideas
      • Start with the biggest risks
      • Perform a Hudson’s Bay Start
      • Prototype
      • Deliver before you deliver
    • 5.5. Improve Communication
      • Interface treaties
      • Enforcement
      • What if they won’t sign?
    • 5.6 Rethink Your Organization
      • What’s needed for a normal project?
      • What every organization needs
      • Start with one little change
    • 5.7 Master Your Fear
      • Rhubarb Cakes for the Queen of the Forest
      • The lesson
  • Part 6. Living With Errors
    • 6.1 The Humpty Dumpty world
    • 6.2 The First Law of Error Defense
    • 6.3 The Second Law of Error Defense
    • 6.4 The Third Law of Error Defense
    • 6.5 The Fourth Law of Error Defense
    • 6.6 The Fifth Law of Error Defense
    • 6.7 The Sixth Law of Error Defense
    • 6.8 The Seventh Law of Error Defense
    • 6.9 The Eighth Law of Error Defense
    • The End, for now
  • Appendix. Error Messages
    • Message Irrelevant
    • Message Contradictory
    • Message Not Clear
    • Clear but Misdirects
    • Message Not Explicit
    • Message Offensive
    • No Message
    • Some Conclusions

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub

Leanpub is copyright © 2010-2018 Ruboss Technology Corp. All rights reserved.