Quality Software: Volume 1.1: How Software Is Built
()
About this ebook
This is part 1 of the latest edition of the classic, Quality Software Management. Its fundamental purpose is to teach how to understand the dynamics of software development organizations, to plan software projects, and to act effectively to carry out those plans.
Gerald M. Weinberg
Gerald M. Weinberg (Jerry) writes "nerd novels," such as The Aremac Project, Aremac Power, First Stringers, Second Stringers, The Hands of God, Freshman Murders, and Mistress of Molecules—about how brilliant people produce quality work. His novels may be found as eBooks at or on Kindle. Before taking up his science fiction career, he 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. He also wrote books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the four-volume Quality Software Management series. He incorporates his knowledge of science, engineering, and human behavior into all of writing and consulting work (with writers, hi-tech researchers, and software engineers). Early in his career, he was the architect for the Mercury Project's space tracking network and designer of the world's first multiprogrammed operating system. Winner of the Warnier Prize and the Stevens Award for his writing on software quality, he is also a charter member of the Computing Hall of Fame in San Diego and the University of Nebraska Hall of Fame. The book, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His website and blogs may be found at http://www.geraldmweinberg.com.
Read more from Gerald M. Weinberg
The Stringers Teaching People Teaching Dogs Rating: 0 out of 5 stars0 ratingsLove Poems After Fifty Years Rating: 0 out of 5 stars0 ratings
Related to Quality Software
Titles in the series (9)
Quality Software: Volume 1.1: How Software Is Built Rating: 0 out of 5 stars0 ratingsWhy Software Gets In Trouble Rating: 0 out of 5 stars0 ratingsChange Done Well Rating: 0 out of 5 stars0 ratingsHow to Observe Software Systems Rating: 0 out of 5 stars0 ratingsResponding to Significant Software Events Rating: 0 out of 5 stars0 ratingsManaging Teams Congruently Rating: 0 out of 5 stars0 ratingsManaging Yourself and Others Rating: 0 out of 5 stars0 ratingsBecoming a Change Artist Rating: 0 out of 5 stars0 ratingsCHANGE: Planned & Unplanned Rating: 0 out of 5 stars0 ratings
Related ebooks
Why Software Gets In Trouble Rating: 0 out of 5 stars0 ratingsManaging Yourself and Others Rating: 0 out of 5 stars0 ratingsThe Fragile Methodology Rating: 0 out of 5 stars0 ratingsThe World Of Agile:Incarnation Of DevOps Rating: 0 out of 5 stars0 ratingsWriting Great Specifications: Using Specification by Example and Gherkin Rating: 0 out of 5 stars0 ratingsBecoming Agile: ...in an imperfect world Rating: 4 out of 5 stars4/5Agile and Lean Program Management: Scaling Collaboration Across the Organization Rating: 5 out of 5 stars5/5Agile ALM: Lightweight tools and Agile strategies Rating: 0 out of 5 stars0 ratingsBDD in Action: Behavior-Driven Development for the whole software lifecycle Rating: 0 out of 5 stars0 ratingsExploring Requirements 2: First Steps into Design Rating: 0 out of 5 stars0 ratingsPerfect Software and Other Illusions About Testing Rating: 5 out of 5 stars5/5Exploring Requirements 1: Quality Before Design Rating: 0 out of 5 stars0 ratingsCHANGE: Planned & Unplanned Rating: 0 out of 5 stars0 ratingsChange Done Well Rating: 0 out of 5 stars0 ratingsBecoming a Technical Leader Rating: 4 out of 5 stars4/5How to Observe Software Systems Rating: 0 out of 5 stars0 ratingsBecoming a Change Artist Rating: 0 out of 5 stars0 ratingsUnderstanding the Professional Programmer Rating: 4 out of 5 stars4/5Design in Object Technology 2: The Annotated Class of 1994 Rating: 0 out of 5 stars0 ratingsAgile Advice - Creating High Performance Teams In Business Organizations Rating: 0 out of 5 stars0 ratingsSuccess Factors for Agile Planning: Agile Planning Successfully and Purposefully - Your Competitive Advantage Rating: 0 out of 5 stars0 ratingsSpecification by Example: How Successful Teams Deliver the Right Software Rating: 0 out of 5 stars0 ratingsPredicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost Rating: 4 out of 5 stars4/5Summary of C. Todd Lombardo, Bruce McCarthy, Evan Ryan & Michael Connors's Product Roadmaps Relaunched Rating: 0 out of 5 stars0 ratingsRoundtable on Technical Leadership Rating: 1 out of 5 stars1/5User Stories A Complete Guide - 2020 Edition Rating: 0 out of 5 stars0 ratingsAgile Aggravations Rating: 3 out of 5 stars3/5
Enterprise Applications For You
QuickBooks 2023 All-in-One For Dummies Rating: 0 out of 5 stars0 ratingsExcel Formulas That Automate Tasks You No Longer Have Time For Rating: 5 out of 5 stars5/5Excel : The Ultimate Comprehensive Step-By-Step Guide to the Basics of Excel Programming: 1 Rating: 5 out of 5 stars5/5Excel 101: A Beginner's & Intermediate's Guide for Mastering the Quintessence of Microsoft Excel (2010-2019 & 365) in no time! Rating: 0 out of 5 stars0 ratingsBitcoin For Dummies Rating: 4 out of 5 stars4/5Excel 2019 For Dummies Rating: 3 out of 5 stars3/5Managing Humans: Biting and Humorous Tales of a Software Engineering Manager Rating: 4 out of 5 stars4/5QuickBooks 2024 All-in-One For Dummies Rating: 0 out of 5 stars0 ratingsExcel 2019 Bible Rating: 5 out of 5 stars5/5Creating Online Courses with ChatGPT | A Step-by-Step Guide with Prompt Templates Rating: 4 out of 5 stars4/5QuickBooks 2021 For Dummies Rating: 0 out of 5 stars0 ratingsCode like a Pro in C# Rating: 0 out of 5 stars0 ratingsAccess 2019 For Dummies Rating: 0 out of 5 stars0 ratingsExcel Data Analysis For Dummies Rating: 0 out of 5 stars0 ratingsEnterprise AI For Dummies Rating: 3 out of 5 stars3/5Excel Formulas and Functions 2020: Excel Academy, #1 Rating: 4 out of 5 stars4/5Excel Workbook For Dummies Rating: 4 out of 5 stars4/5Notion for Beginners: Notion for Work, Play, and Productivity Rating: 4 out of 5 stars4/5Mastering QuickBooks 2020: The ultimate guide to bookkeeping and QuickBooks Online Rating: 0 out of 5 stars0 ratingsLearning Python Rating: 5 out of 5 stars5/5Splunk Essentials - Second Edition Rating: 0 out of 5 stars0 ratingsExcel All-in-One For Dummies Rating: 0 out of 5 stars0 ratings50 Useful Excel Functions: Excel Essentials, #3 Rating: 5 out of 5 stars5/5
Reviews for Quality Software
0 ratings0 reviews
Book preview
Quality Software - Gerald M. Weinberg
QUALITY SOFTWARE
VOLUME 1.1: HOW SOFTWARE IS BUILT
by
Gerald M. Weinberg
SMASHWORDS EDITION
* * * * *
PUBLISHED BY:
Gerald M. Weinberg on Smashwords
Quality Software
Volume 1.1: How Software Is Built
Copyright © 2010 by Gerald M. Weinberg
All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.
Smashwords Edition License Notes
This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.
Contents
Part I. Patterns of Quality
Chapter 01. What is Quality?
1.1 A Tale Of Software Quality
1.2 The Relativity of Quality
1.2.1. Finding the relativity
1.2.2 Who was that masked man?
1.2.3 The political dilemma
1.3 Quality Is Value To Some Person
1.4 Another Story About Quality
1.5. Why Improving Quality Is So Difficult
1.5.1. It’s not too bad.
1.5.2. It’s not possible.
1.5.3. The lock-on
1.6. Software Culture and Subcultures
1.7. Helpful Hints and Suggestions
1.8 Summary
1.9 Practice
Chapter 02. Software Quality Patterns
2.1 Applying Crosby’s Ideas to Software
2.1.1 Conformance to requirements is not enough
2.1.2 Zero Defects
is not realistic in most projects
2.1.3 There is an economics of quality
2.1.4 Any pattern can be a success
2.1.5 Maturity
is not the right word
2.2 Six Software Sub-Cultural Patterns
2.3 Pattern 0: Oblivious
2.4 Pattern 1: Variable
2.4.1 The superprogrammer image
2.4.2 When Pattern 1 is successful
2.4.3 The ideal development structure
2.5 Pattern 2: Routine (but Unstable)
2.5.1 The superleader image
2.5.2 When Pattern 2 is successful
2.5.3 The ideal development structure
2.6 Pattern 3: Steering
2.6.1 The competent manager
2.6.2 When Pattern 3 is successful
2.6.3 The ideal development structure
2.7 Pattern 4: Anticipating
2.8 Pattern 5: Congruent
2.9. Helpful Hints and Variations
2.10. Summary
2.11. Practice
Chapter 03. What Is Needed To Change Patterns?
3.1 Changing Thought Patterns
3.1.1 Thought and communication in various patterns
3.1.2 Using models to change thinking patterns
3.1.3 How precise should the models be?
3.1.4 What models do for us
3.2 Choosing A Better Pattern
3.2.1 Is your present pattern good enough?
3.2.2 Organizational demands
3.2.3 Customer demands
3.2.4 Problem demands
3.2.5 Choosing a point in pattern space
3.2.6 The temptation to stagnate
3.3 Opening Patterns to Information
3.3.1 Circular argument
3.3.2 The classic software circle
3.3.3 The key to opening closed circles
3.3.4 Developing trust
3.4. Helpful Hints and Variations
3.5. Summary
3.6. Practice
Part II. Patterns of Managing
Chapter 04. Control Patterns for Management
4.1 Shooting at Moving Targets
4.2 The Aggregate Control Model
4.2.1 Aggregation in the software industry as a whole
4.2.2 Aggregation in a single organization
4.2.3 Natural selection in a Pattern 1 Organization
4.2.4 Why aggregation is popular in Pattern 2 organizations
4.2.5 Aggregation in other patterns
4.3 Patterns and Their Cybernetic Control Models
4.3.1 The system to be controlled (the focus of Patterns 0 and 1)
4.3.2 The controller (the focus of Pattern 2)
4.3.3 Feedback control (the focus of Pattern 3)
4.4 Engineering Management
4.4.1 The job of management
4.4.2. No plan for what should happen
4.4.3. Failure to observe what significant things are really happening
4.4.4. Failure to compare the observed with the planned
4.4.5. Not taking action to bring actual closer to planned
4.5. From Computer Science to Software Engineering
4.6. Helpful Hints and Variations
4.7. Summary
4.8. Practice
Chapter 05. Making Explicit Management Models
5.1 Why Things Go Awry
5.1.1 The role of system models
5.1.2. Implicit models
5.1.3 Inability to face reality
5.1.4 Incorrect models
5.2 Linear Models and Their Fallacies
5.2.1 5.2.1 Addititivity fallacies
5.2.2 Scaling fallacies
5.3 The Diagram of Effects
5.4 Developing a Diagram of Effects from Output Backwards
5.4.1. Starting with the output
5.4.2. Brainstorming backwards effects
5.4.3. Charting the backwards effects
5.4.4. Charting secondary effects
5.4.5. Tracing the secondary effects
5.4.6. Explicitly indicating multiplicative effects
5.5. Non-linearity Is the Reason Things Go Awry
5.6. Helpful Hints and Suggestions
5.7. Summary
5.8. Practice
Chapter 06. Feedback Effects
6.1 The Humpty Dumpty Syndrome
6.2 Runaway, Explosion and Collapse
6.2.1. The Reversible Fallacy
6.2.2. The Causation Fallacy
6.2.3. Irreversibility: explosion or collapse
6.3. Act Early, Act Small
6.3.1 Brooks’s Law made worse by management action
6.3.2 The Generalized Brooks’s Law
6.4. Negative Feedback—Why Everything Doesn’t Collapse
6.4.1 A system waiting for a disaster to happen
6.4.2 Negative feedback loops
6.4.3 How feedback loops regulate
6.5. Helpful Hints and Suggestions
6.6. Summary
6.7. Practice
Chapter 07. Steering Software
7.1. Methodologies and Feedback Control
7.1.1 Plans: the great contribution of Pattern 2
7.1.2 Why pure sequential methods don’t always work
7.1.3 Methodologies can discourage innovation
7.1.4 Adding feedback to the methodology
7.1.5 Keeping the feedback early and small
7.1.5 Applying the feedback at different levels
7.2. The Human Decision Point
7.2.1 Intervention models and invisible states
7.2.2 Visualizing the invisible
7.3 It’s Not The Event That Counts, It’s Your Reaction To The Event
7.4 Helpful Hints and Suggestions
7.5 Summary
7.6 Practice
Chapter 08. Failing to Steer
8.1. I’m a Victim
(unable to take action)
8.2. I Don’t Want to Hear Any of That Negative Talk.
8.3. I Thought I Was Doing The Right Thing.
8.4 Helpful Hints and Suggestions
8.5 Summary
8.6 Practice
Part III. Demands That Stress Patterns
Chapter 09. Why It Will Always Be Hard to Steer
9.1. The Game of Control
9.1.1 The Square Law of Computation
9.1.2 Control as a game
9.1.3 How complex is chess?
9.1.4 Computational complexity
9.1.5 Simplification by general principles
9.1.6 The Size/Complexity Dynamic
9.2 The Size/Complexity Dynamic in Software Engineering
9.2.1 The history of software
9.2.2 The history of software engineering
9.2.3. Games against Nature
9.2.4. The Fault Location Dynamic
9.2.5 The Human Interaction Dynamic
9.3 Helpful Hints and Suggestions
9.4 Summary
9.5 Practice
Chapter 10. What It Takes To Be Helpful
10.1 Reasoning Graphically about the Size/Complexity Dynamic
10.1.1. Size vs. brainpower
10.1.2 The size vs. effort curve
10.1.3 Variation and the Log-Log Law
10.2 Comparing Patterns and Technologies
10.2.1. Comparing with a size/effort curve
10.2.2 Seeing through the data
10.2.3 Combining two methods into a composite pattern
10.2.4 Choosing for reasons other than effort
10.2.5. Reducing the risk of change
10.3 Helpful Interactions
10.3.1. Do no harm.
10.3.2 The Helpful Model
10.3.3 The Principle of Addition
10.3.4. Adding to the repertoire of models
10.4 Helpful Hints and Suggestions
10.5 Summary
10.6 Practice
Chapter 11. Responses to Customer Demands
11.1 Customers Can Be Dangerous To Your Health
11.1.1 More customers increase the development load
11.1.2 More customers increase the maintenance load
11.1.3 Close contact with customers can be disruptive
11.1.4 You can be disruptive to your customers
11.1.5 What happens when you have many customers
11.2 The Cast of Outsiders
11.2.1 Customers and users
11.2.2 The marketing department
11.2.3 Other surrogates
11.2.4 Programmers as self-appointed user surrogates
11.2.5 Testers as official and unofficial surrogates
11.2.6 Other unplanned surrogates
11.3 Interactions With Customers
11.3.1 The dynamics of interruption
11.3.2. Interrupted meetings
11.3.3 Meeting size and frequency
11.4 Configuration Support
11.4.1 Effects on test coverage and repair time
11.4.2 Analyzing the testing situation externally—an Apple example
11.5 Releases
11.5.1 Pre- and post-release dynamics
11.5.2 Multiple versions
11.5.3 Release frequency
11.6. Helpful Hints and Suggestions
11.7. Summary
11.8. Practice
* * * * *
QUALITY SOFTWARE MANAGEMENT:
VOLUME 1: SYSTEMS THINKING
* * * * *
New Preface
Teachers not only teach, but they also learn.
- Sauk saying
This book is a kind of an Anniversary present, commemorating my now-50-year love affair with computers. In the 40 years since I first sat at my computer to write down what I had learned in my first 40 years in the computer business, I've learned an enormous amount. Much of it has been written in the second, third, and fourth volumes of Software Quality Management. Some has been written in a variety of other books and articles, including, Amplifying Your Effectiveness (edited with Naomi Karten and James Bach), What Did You Say? : The Art of Giving and Receiving Feedback (with Edie and Charlie Seashore; Perfect Software--and Other Illusions About Testing; the Roundtable on Project Management and the Roundtable on Technical Leadership (both edited with Jim Bullock, and Marie Benesh); Weinberg on Writing: The Fieldstone Method; and More Secrets of Consulting: The Consultant's Self-Esteem Tool Kit.
There are also my novels, including, so far, the Aremac series, the Stringers series, Earth's Endless Effort, Mistress of Molecules, Freshman Murders, and The Hands of God–each of which attempts to bring lessons to the reader through the medium of compelling stories of adventure. And one of the major reasons I've been writing novels and in other formats is what I've learned from reader feedback.
Typical of this learning when I read a book review written by my good friend, Dan Starr. About somebody else’s book, he wrote, This book is a gold mine.
The next time I saw him, I asked him why he never called one of my books a gold mine.
You know what a gold mine is like,
he replied. There are a few gold nuggets, but you have to sift through tons of worthless tailings to find them.
I was starting to feel better, but then he added, Your books are more like coal mines.
Oh?
was all I could muster.
Yes. You know what a coal mine is like. Every shovelful contains something worthwhile. Every one.
I'm satisfied to be writing coal mines. Oh, sure, I once imagined that I could write a book in which every sentence, every word, would be 24-karat gold, but nobody can sustain that level for an entire book. Even the Greatest Book Ever Written
has long boring, repetitious passages that not even the most ardent evangelist will ever quote. So, if even God won't write a solid gold book, I'm content to drop that particular fantasy.
But, readers tell me that compared with lots of other books, my books are dense, dense, reading. A common complaint about the Quality Software Management Series is this: They're just too expensive and too big to take in all at once.
So, when Volume I went out of print for a while (they're also expensive to print), I took another look and decided to break it into smaller, less expensive volumes.
I also learned that for many potential readers outside of the United States, simply paying the shipping for one of those volumes more than doubled the cost–in Americanb dollars, no less. So, to make them available to non-Americans (and some Americans, too), I've chosen to make eBook versions, as well.
I've also learned that much of the heaviness
of those volumes came from all the scholarly material, such as footnotes and references. Nowadays, with search engines on the internet, readers who wish to follow up on something they read don't really need those references. By omitting them, I make the volumes lighter, and shorter. And friendlier to the average modern reader.
The principal contents, on the other hand, are largely unchanged. I was writing about general principles–illustrated by specific examples–much of which derived from my Introduction to General Systems Thinking and General Principles of System Design (with Dani Weinberg). There are, of course, new examples from the Internet Age, but the fundamental principles remain the same.
For the modern reader, I suggest they add Practice problems based on their more recent experiences. For me to add such examples throughout would be such an overwhelming task it would delay the books by a number of years. And that's one more thing I hear from my readers:
Get the books out there for us. Don't delay!"
One more explanation. I've taken the word management
out of the title, leaving, simply, Quality Software.
Why? Because too many people who should be reading this material interpreted management
to mean managers.
Certainly these books are for managers, but they're also for everyone else in the business of producing quality software.
I've learned anew that most of the improvements in our business do not come from managers, but from underneath. As many have said, Change always comes from the bottom. Nobody holding four Aces has ever asked for a new deal.
And that's why I'm hoping that these format changes will empower everybody to create a new deal in software.
Preface
Poor management can increase software costs more rapidly than any other factor.
- Barry Boehm
This book is a kind of an Anniversary present, commemorating my 40-year love affair with computers. Early in 1950, I read a Time magazine cover story about computers, or Thinking Machines.
The cover itself was by Time’s favorite cover artist, Artzybashef. It depicted an anthropomorphic electronic box with an eye looking at a paper tape held in its right hand while its left hand typed some output on a teletype. The box was topped with a Navy cap with lots of scrambled eggs,
and the caption read, Mark III. Can man build a superman?
A bit sensational, yes, but it made a profound impression on a 16-year-old about to graduate from high school. I may not recall many details of the article, but I clearly recall that I decided on the spot computers would be my life.
One of the facts that impressed me in the article was that IBM was a big factor in the business of building computing machines. In 1956, when I was unable to find a university that taught about computers, I went to work for IBM.
For 13 years, I took IBM seriously, especially the THINK part. IBM was right. Thinking was essential. But after a while I noticed that IBM and its customers often honored thinking, but didn’t practice it. Especially in the software side of the business, which always seemed to take last place in the hearts of IBM executives.
As far as I could tell, little THINK signs on each desk never helped us get software out the door. Yet IBM managers never seemed to do much else to help the process. Later, after I left IBM for an independent consulting career, I learned that IBM’s managers were no different from the rest.
All over the world, software managers gave lip service to thinking, but didn’t do much about it. For one thing, they never understood the reasons that people didn’t think when they ought to. Of course, I didn’t understand either.
Looking back, I realize why the Time article had so impressed me. In school, everyone told me how smart I was. True, I did outstanding work on all sorts of tests, but I never seemed to be able to think effectively about my own life. I was a miserable kid, and I thought that thinking machines
might help me solve my problems.
Well, thinking machines
didn’t solve my problems—they made them worse. When I tried to build software, the computer unfailingly accentuated all my mistakes. When I didn’t think right about a program, the program bombed. The computer, I learned, was a mirror of my intelligence, and I wasn’t too impressed by my reflection.
Later, when I wrote larger programs in concert with other people, I learned that the computer was not just a mirror, but a magnifying mirror. Any time we didn’t think straight about our software project, we made a colossal monster. I began to learn that if we were ever to make good use of thinking machines,
we would have to start by improving our own thinking.
I began to study thinking as a subject in itself, particularly thinking as applied to software problems. Through the generosity of IBM, I went back to school and wrote a thesis on using computers as tools to mirror our minds. I travelled all over the world, visiting software organizations and studying how they think—about software. I shared ideas with people, and tried to put those ideas in practice on software projects. I observed what worked and what didn’t—and I revised my ideas. I published some of them and then used feedback from hundreds of readers to refine them. This book summarizes what I have learned up to now about managing software projects effectively.
Why is managing software projects so important? One of the predictions in that ancient Time article was the following:
Around each working computer hover young mathematicians with dreamy eyes. On desks flecked with frothy figures, they translate real-life problems into figure-language. It usually takes them much longer to prepare a problem than it takes the machine to solve it.
These human question-answerers are sure to lag farther and farther behind the question-answering machines.
Not all of the predictions in the article came true (up until now), but this one certainly did. Since that day when I became one of