System Design Heuristics
Minimum price
Suggested price

System Design Heuristics

About the Book

You'd think that after publishing books for half a century, I'd know how to write a book. If that's what you think, you'd be wrong.

Sure, I've even written a book on writing books (Weinberg on Writing, the Fieldstone Method), and I've applied those methods to dozens of successful books. But way back around 1960, I started collecting notes on the process of design, thinking I would shortly gather them into a book. Back then, I didn't call these bits and pieces "fieldstones," but that's what they turned out to be: the pieces that, when assembled properly, would ultimately become my design book.

Ultimately? Assembled properly? Aye, there's the rub!

Building walls from randomly found fieldstones requires patience. So does writing books by the Fieldstone Method. My Introduction to General Systems Thinking took fourteen years to write. But a writer only lives one lifetime, so there's a limit to patience. I'm growing old, and I'm beginning to think that fifty years is as close to "ultimately" as I'm going to get.

So, I've begun to tackle the task of properly assembling my collection of design fieldstones. Unfortunately, it's a much larger collection that I'd ever tackled before. My Mac tells me I have more than 36,000,000 digitized bytes of notes. My filing cabinets told me I had more than twenty-five pounds of paper notes, but I've managed to digitize some of them and discard others, so there's only a bit more than ten pounds left to consider.

For the past couple of years, I've periodically perused these fieldstones and tried to assemble them "properly." I just can't seem to do it. I'm stuck.

Some writers would say I am suffering from "writer's block," but I believe "writer's block" is a myth. I've published three other books in these frustrating years, so I can't be "blocked" as a writer, but just over this specific design book. You can hear me talk more about the Writer's Block myth on YouTube


but the short version is that "blocking" is simply a lack of ideas about how to write. I finally decided to take my own advice and conjure up some new ideas about how to write this design book.

Why I Was Stuck

To properly assemble a fieldstone pile, I always need an "organizing principle." For instance, my recent book, Do You Want to Be a (Better) Manager? is organized around the principle of better management. Or, for my book, Errors, the principle is actually the title. So, I had been thinking the organizing principle for a book on design ought to be Design

Well, that seemed simple enough, but there was a problem. Everybody seemed to know what design is, but nobody seemed able to give a clear, consistent definition that covered all my notes. I finally came to the conclusion that's because "design" is not one thing, but many, many different things.

In the past, I ran a forum (SHAPE: Software as a Human Activity Practiced Effectively) whose members were among the most skilled software professionals in the world. We held a number of threads on the subject, "What is Design?" The result was several hundred pages of brilliant thoughts about design, all of which were correct in some context. But many of them were contradictory.

Some said design was a bottom-up process, but others asserted it was top-down. Still others talked about some kind of sideways process, and there were several of these. Some argued for an intuitive process, but others laid out an algorithmic, step-by-step process. There were many other variations: designs as imagined (intentional designs), designs as implemented, and designs as evolved in the world. All in all, there were simply too many organizing principles—certainly too many to compress into a title, let alone organize an entire book.

After two years of fumbling, I finally came up with an idea that couldn't have been implemented fifty years ago: the book will be composed of a variety of those consulting ideas that have been most helpful to my clients' designers. I will make no attempt (or very little) to organize them, but release them incrementally in an ever-growing ebook titled Design Heuristics.

How to Buy System Design Heuristics

My plan for offering the book is actually an old one, using a new technology. More than a century ago Charles Dickens released many of his immortal novels one chapter at a time in the weekly newspaper. Today, using the internet, I will release System Design Heuristics a single element at a time to subscribing readers.

To subscribe to the book, including all future additions, a reader will make a one time payment. The price will be quite low when the collection is small, but will grow as the collection grows. That way, early subscribers will receive a bargain in compensation for the risk of an unknown future. Hopefully, however, even the small first collection will be worth the price. (If not, there will be a full money-back guarantee.)

Good designs tend to have unexpected benefits. When I first thought of this design, I didn't realize that it would allow readers to contribute ideas that I might incorporate in each new release. Now I aware of that potential benefit, and look forward to it.

Before I upload the first increment of System Design Heuristics, I'll wait a short while for feedback on this idea from my readers. If you'd like to tell me something about the plan, email me or write a comment on this blog.

Thanks for listening.

  • Share this book

  • Categories

    • Design
    • Systems Engineering
    • Software Architecture
  • 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 <>; on Amazon at; and at Barnes and Noble bookstore:

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
    • Why I Was Stuck
    • How to Buy System Design Heuristics
  • About the Author
  • Principles
    • What Is Design?
    • Misconception: Only Designers Design
    • Misconception: Design Is Higher Status
    • Designer Culture
      • Marking the Boundaries
      • The Great Wall of China syndrome
      • Meeting the Natives
      • Building Cultural Bridges
    • What Versus How
    • Who Matters?
    • When Does Design Happen?
    • Why Do We Need Design?
    • How Much?
    • Learning the Magic of Design
      • Luck and Magic in Design
        • Three wishes
        • Return to zero
  • Individual Heuristics
    • How Design Begins
      • What Must Not Change?
      • A Solution Looking for a Problem
      • Designing This Book
    • Why Are We Doing This?
    • Zero-level Solution
      • A Zero-Level Example
      • Random designs
    • The Rule of Three
      • A bet I lost
      • The Rule of Three
      • The Rule of Three in problem definition
      • The Rule of Three in software testing
      • The Rule of Three in designing
    • Loosening Up Your Thinking
      • Look for Analogies
      • Move to Extremes
      • Look Outside the Boundary
      • Look for Alibis Versus Explanations
      • The Emotional Component
      • The Incongruence Insight
      • Brown’s Brilliant Bequest
    • Designing with All Sides of the Brain
      • A Sequence of Models of Programming
      • The Cognitive Side
      • Process versus Product
      • The Emotional Side
      • An Improved Model of Programming
      • The Neglected Models
      • Moral Models
      • The Social Environment
    • Where Ideas Come From
      • Error
      • Theft
      • Theft Plus Error
      • Copulation
    • Design Wagers Checklist
    • Anthropomorphism
    • Rituals
    • KISS, or Keyp Itt Simpel Stoopid
      • Why Must Designers Simplify?
      • The Square Law of Computation
    • Consistency
      • People are different
      • Satisfying expectations
    • The Cybercrud Cudgel
      • A Word to designers
    • Undo
    • Double Design
      • Double design examples
      • What’s necessary to succeed in double-design
      • Putting Two Problems Together
    • Estimating
      • Jim’s Estimation Exercise
      • Bonus Meta-questions:
      • Some answers
  • Heuristics About Getting Information
    • Heuristics About Asking Questions
    • Difficult Questions
      • Some difficult questions
    • Visualizing
      • The Guinness Book of Records exercise
      • The perfect method of ranking
      • Not all visualizing is visual
      • Changing point of view
    • Bad Decision Making
      • Control by eyebrow
      • A lousy decision process
    • Designing to Intimidate
      • The History and Psychology of Intimidation
      • The IT Center as Intimidator
      • They’ll Be Back
      • Filling in forms
      • Insolent error messages
      • Big bad manuals
      • Rude treatment
      • Slow service
      • Jargon
      • What’s Our Business, Anyway?
      • Who does your design intimidate?
    • Who uses the system?
      • The anthropology exam
      • The first ATM robbery
      • The plumber on the stock exchange
      • Changing point of view
  • Tradeoffs
      • Tradeoffs change with time
      • Features become errors
    • Constraints
      • The First Law of Software Engineering
    • Performance By Design
      • The First Searching Axiom
      • The Second Searching Axiom
      • Divide and conquer
      • Binary search
      • The First Foundation of Effective Computing
      • The Second Foundation of Effective Computing
      • The Third Foundation of Effective Computing
    • In Praise of Efficiency
      • Is enough enough?
      • Worst-first optimization
      • The First Rule of Optimization
      • The Curse of Optimization
    • Now versus later
      • What do we know about the future?
      • Lifetimes
      • Robust Designs
      • What do we know about the past?
  • Size
      • Standard parts
    • Scale
      • Dispersion of work
      • Dispersion of demands
      • Large numbers of users
      • Hack Attract
      • Growth produces bigness
      • The Astronomical Test
      • How much output?
      • Failing to scale
      • Long-life systems
    • The JIGSAW analogy
    • Passing to the limit
      • Light loads
      • Designing the startup
    • Crowding effects
      • The Tragedy of the Commons
      • The Public Address Law
      • Deadlocks
    • Segmented systems
      • Problem avoidance through modularization
      • Fully integrated?
      • Poor modularization
      • Interface treaties
      • Management support for design
  • Evolution Heuristics
      • The Axiom of Experience
      • Fisher’s Fundamental Theorem of Natural Selection
    • Designs change their assumptions
      • A FORTRAN story
      • Implementation challenges assumptions
      • The Highway Law
  • Feedback
      • A Design So Bad It’s Good (for a Laugh)
      • Every designer’s ideas must be tested
    • Design reviews
      • Example: Out-of-date documents
      • How Important Are Design Reviews?
      • General rules about reviews
      • Which design level is the better choice for reviews?
      • What about reviewing logical vs. physical design?
      • Isn’t correct or incorrect a matter of opinion with designs?
      • Is it possible, then, to develop checklists for design reviews?
      • The BCS Preliminary Design Document Review Checklist
  • Heuristics for designer behavior
      • Humility
      • Congruence with tools
      • Be as direct as possible
      • Know why
      • Say why
      • Be wary of your tools
      • Stay congruent with what’s important
    • Politics
      • Who defines goodness?
      • Political vs. technical solutions
      • Know about people
      • Care about people
      • Designs or excuses?
      • Blaming the victim
      • A drastic design approach
      • A reasonable design approach
      • Use people as a valuable resource
      • Ford’s Fundamental Feedback Formula
      • Speculation
      • Average or extreme?
      • What constitutes design success?
      • Leading the people
      • Delegating tasks
  • Also By Gerald M. Weinberg
    • Non-fiction
    • Fiction

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...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

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

In fact, authors have earnedover $13 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