Errors
$9.99
Minimum price
$9.99
Suggested price

Errors

Bugs, Boo-boos, Blunders

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

  • Share this book

  • Categories

    • Project Management
    • Computers and Programming
    • Testing
    • Systems Engineering
    • Management
    • Software Engineering

  • Feedback

    Email the Author(s)

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

Other books by this author

System Design Heuristics
Gerald M. Weinberg
The Psychology of Computer Programming
Gerald M. Weinberg
Becoming a Technical Leader
Gerald M. Weinberg
Exploring Requirements Two
Gerald M. Weinberg
Exploring Requirements One
Gerald M. Weinberg
Are Your Lights On?
Gerald M. Weinberg
General Systems Thinking
Gerald M. Weinberg
Perfect Software
Gerald M. Weinberg
The Aremac Project
Gerald Weinberg
Handbook of Technical Reviews, Fourth Edition
Gerald M. Weinberg
What Did You Say? The Art of Giving and Receiving Feedback
Gerald M. Weinberg
Agile Impressions
Gerald M. Weinberg
Freshman Murders
Gerald M. Weinberg
PSL Reader
Johanna Rothman, Esther Derby, Don Gray, and Gerald M. Weinberg

The Leanpub 60 Day 100% Happiness Guarantee

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

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $14 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

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. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub

Publish Early, Publish Often

  • Path
  • There are many paths, but the one you're on right now on Leanpub is...
  • › Errors

*   *   *

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

This site is protected by reCAPTCHA
and the Google Privacy Policy and Terms of Service apply.