It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we are going to take a look at what I consider the first book in Jerry’s seminal series on managing quality software: Quality Software Management Volume 1 – Systems Thinking published by Dorset House Publishing in 1992.

Review on Amazon

A while back, I reviewed this book on Amazon:

The basis for managing towards Quality Software

In the first volume, Jerry provides the cultural pattern model and relates it to the CMM levels and other approaches taken. Interestingly his view includes the culture around the people actually producing the software in the first place, while other models focus on anything else but the people. First and foremost, Jerry defines quality as “value to some person”. Based on this definition, the question we have to ask in software development – which I define as programming, testing, and delivering – is whose values count most to us.

Additionally, Jerry introduces the reader to systems thinking. That is a model to think through difficult and maybe complex situations in software projects. He shows many graphs applying systems thinking, thereby creating deep insights into each of the cultural models, as well as the dynamics around the creation and maintenance of software.

Using systems thinking Jerry introduces the non-linearity of aspects of software development. He revisits Brook’s Law and generalizes it to hold not only for late projects, but for any project, when adding people, you’re making it more complicated, and maybe even later.

A blast from the past

Let’s see what changed in the 10+ years since then. I recall that Jerry in Volume 1 came up with a taxonomy of corporations in the software development business from oblivious to “proficient”, but I don’t recall the exact terms. Looking them up, Jerry called them patterns with the following meaning:

• Pattern 0: Oblivious When you do something in Excel or a spreadsheet, you may end up programming something without directly knowing that you are programming. Jerry calls this pattern of software sub-cultures oblivious to the fact that you are even creating software.
• Pattern 1: Variable Here, the company is aware they are producing software, but with variable results.
• Pattern 2: Routine The company worked on reducing its variability and producing software in a routine fashion with somewhat predictable results
• Pattern 3: Steering The company is able to steer the quality of its software.
• Pattern 4: Anticipating The company anticipates changes and can deal with them.
• Pattern 5: Congruent The company acts congruent internally and externally and maintains the same congruent messages throughout.

At least, that is how I would frame these patterns in my mind.

Of course, in Volume 1 – as the subtitle suggests – Jerry gives a brief introduction to Causal Loop Diagrams from the Systems Thinking field. Jerry describes a couple of his points in terms of causal loop diagrams and draws lines from effects to root causes and how they encircle a dynamic. Here in Volume 1 for example he draws a line for the effects of multi-tasking where he gives the following table:

A rule-of-thumb can help when estimating the effects of splitting tasks. the following table is what I use:

Number of tasks	% of Time on Each
1	100%
2	40%
3	20%
4	10%
5	5%
more than 5	random

Sometimes you do better than this for certain people for short periods of time, but if you plan on doing better, your plan will fail.

Quality Software Management – Volume 1: Systems Thinking, Gerald M. Weinberg, Dorset House, 1992, page 284

In the chapter presiding this table, Jerry explores the causal loop diagram around deciding to ship a faulty product to the market or its users.

With his first volume in the Quality Software Management series, Jerry provides the reader with the basics of causal loop diagrams, which he continues to use in the next volumes to explain several aspects and drawbacks, as well as introduce the taxonomy used throughout the series. I consider it groundbreaking for the things to come.

Some personal gems

I’ll conclude this review with some personal gems about my version of Quality Software Management Volume 1.

On the first Agile Testing Days 2009 in Berlin, I asked Elisabeth Hendrickson to sign my copy of Quality Software Management Volume 1, since she introduced herself as a student of Jerry during her tutorial session that I attended. I was reading Volume 1 back then, and since we followed each other on Twitter for a while, I figured it was a good way to keep memories of her.

After finishing the first or maybe second Quality Software Management Volume, I figured that Jerry kept a list of all the reminders for the readers in the book of the books. At some point, I decided to write them up and keep them for my personal references. In case you wondering, this is how I can relate to particular pages whenever I cite something from Jerry. I thought it would be neat to share this collection. I did not separate the different volumes into different files. So, here is the full list of laws, rules, and principles from the four Quality Software Management volumes. (And in case you are wondering, yes, I noted these down in LaTeX and compiled them into a pdf.)

These lists will probably only make sense to you if you read the books. Also note, that Jerry, later on, published an updated version of Quality Software Management, and I think he basically split each of the books into two or three smaller ones at the time. If you read those, the page numbers will not fit, and I don’t know how much he changed between the Dorset House and the later published ones.