System Design Heuristics
Last updated on 2018-06-21
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.
- Why I Was Stuck
- How to Buy System Design Heuristics
- About the Author
- What Is Design?
- Misconception: Only Designers Design
- Misconception: Design Is Higher Status
- 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
- Luck and Magic in Design
How Design Begins
- What Must Not Change?
- A Solution Looking for a Problem
- Designing This Book
- Why Are We Doing This?
- 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
- Theft Plus Error
- Design Wagers Checklist
KISS, or Keyp Itt Simpel Stoopid
- Why Must Designers Simplify?
- The Square Law of Computation
- People are different
- Satisfying expectations
The Cybercrud Cudgel
- A Word to designers
- Double design examples
- What’s necessary to succeed in double-design
- Putting Two Problems Together
- Jim’s Estimation Exercise
- Bonus Meta-questions:
- Some answers
- How Design Begins
Heuristics About Getting Information
- Heuristics About Asking Questions
- Some difficult questions
- 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
- 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 change with time
- Features become errors
- 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?
- Robust Designs
- What do we know about the past?
- Standard parts
- 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
- The Tragedy of the Commons
- The Public Address Law
- Problem avoidance through modularization
- Fully integrated?
- Poor modularization
- Interface treaties
- Management support for design
- The Axiom of Experience
- Fisher’s Fundamental Theorem of Natural Selection
Designs change their assumptions
- A FORTRAN story
- Implementation challenges assumptions
- The Highway Law
- A Design So Bad It’s Good (for a Laugh)
- Every designer’s ideas must be tested
- 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
- Congruence with tools
- Be as direct as possible
- Know why
- Say why
- Be wary of your tools
- Stay congruent with what’s important
- 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
- Average or extreme?
- What constitutes design success?
- Leading the people
- Delegating tasks
Also By Gerald M. Weinberg
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
Free Updates. Free App. 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), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). 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.