My journey with Jerry Weinberg

I came across this blog entry earlier this week. While I also can resonate with most of the books that Soronthar read from Jerry, I felt like to tell my own story with Jerry’s books. Among my colleagues I am most well-known to cite a lot from Jerry’s work – mostly that is because I took the effort to type-copy the references to his meaningful laws on my computer, so that I can pull out Rudy’s Rutabaga Rule from the Secrets of Consulting quite easily:

Once you eliminate your number one problem, number two gets a promotion. (The Secrets of Consulting, page 15)

But that’s not where my story with Jerry started. Here’s the full story.

One word of disclaimer: I know a lot of people that are not comfortable reading Jerry’s books. To most of them I have a lot of respect. And I think it’s ok, if you can’t read his books. I am just going to share, what I learned, and what sticks even years later.

The first piece I read from Jerry was in Project Retrospectives. Yeah, he didn’t write the book, Norm Kerth did. But Jerry wrote the foreword. Back then, I was not aware that he wrote that foreword. I also know that Norm Kerth has been a student of Jerry, and was probably heavily influenced by him.

The first complete book was Becoming a Technical Leader – An Organic Problem-Solving Approach. The stuff that sticked mostly from that were the Motivation – Organization – Innovation pillars for leadership, and his three obstacles to innovation, and how to overcome them. To make a long story short, you can only innovate if you happen to learn from your failures, look what others are doing, and combine two great things with each other. For the third piece, I think I ended up doing that a lot of times.

Back then, Matt Heusser made me aware that Jerry had written a book on testing: Perfect Software… and other illusions about testing – together with James Bach. Jerry explains the Satir Interaction model in the book, and describes the dilemma of the Composition and Decomposition Fallacy in Software Testing. There are many more lessons in there, but these two sticked the most with me over the course of the past three years.

Immediately after that I had to get through the Quality Software Management series. Starting with Quality Software Management Volume 1 – Systems Thinking my journey in systems thinking started. With his diagrams of effect, I was easily made aware of certain systemic effects in the world I lived in back then. Of course, the fundamental definition of quality still sticks with me from page 7:

Quality is value to some person.

I followed up with Quality Software Management Volume 2 – First-order measurement. Here I learned the problems with replacement measures like lines of code, or estimated story points, or bug counts. In the second volume Jerry also introduced the Satir Interaction model, and I firstly became attracted to the Rule of Three interpretations:

If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.

In Quality Software Management Volume 3 – Congruent Action I learned about Satir’s concept of congruency, and what might trouble me if the words I spoke and my actions did not match each other.

Quality Software Management Volume 4 – Anticipating Change finally helped me understand the MBTI model, and the different forces a change agent will face. Together with the Satir Change model, I learned a lot about human psychology in the software business.

Back then, I was about to start my job at it-agile GmbH. That’s why I started diving into The Secrets of Consulting and directly followed by More Secrets of Consulting. These two books helped me see a lot of stuff that I am still digesting years later. Not only about pricing, and finding a job as a consultant, but also about attitudes when it comes to dealing with a potential and not-so-potential client.

After that I took a deeper look into Are your lights on? – How to figure out what the problem really is, co-written with Don Gause. The two authors give broad examples of problems which could have been solved in another way, but finally were solved more cleverly. This is an essential lesson to some of the developers out there, that try to solve any problem by writing a program – sometimes to the extent to write a program that writes programs. The story in particular that influenced the title of the book still sticks with me.

Then I went on to Amplifying your Effectiveness which is in essence a collection of essays from various authors for the first AYE conference. The final one was last year, and I never got to attend it. Still, I learned a lot from all the hosts from the first AYE conference – on psychology, leadership, and what their role in software development is.

An Introduction to General Systems Thinking was an interesting read, but not so much sticked with me over the years. The whole book boils down to “thinking in General systems is a fruitless effort” – at least for me. It was interesting though to dive into the various stories Jerry told along the line.

At the time I was writing ATDD by example on my own, I dived deeper into requirements gathering. Exploring Requirements – Quality before design is a must-read in this regard. This is not only the origin of the famous story about the Swedish Army dictum, but also a source of so many insights on what requirements gathering is all about, and what it is not about.

After that, I dived into Weinberg on Writing – The Fieldstone method. Besides providing me a few tricks on my own writing, I also learned about the fieldstone method, and that a writer can only become better by writing. I still have to find a way to organize all my stuff well enough. One of these days I am going to fiddle a way to use fieldstones more effectively. So far, I have not been able to do so.

Directly after attending PSL in May 2011, I brought home a two more books from Jerry which I wasn’t able to get in Germany before that. Rethinking Systems Analysis and Design was one of these two – the other I still need to read. Together with Exploring Requirements I finally grasped what requirements gathering, design, and implementation tried to eventually achieve in the earlier days of programming. There are traces left in our industry, and it seems we finally got our head around these topics.

Not a book by Jerry, himself, but for his 75th birthday, The Gift of Time was next on my journey. A lot of people describe their very own journeys with Jerry over the course of the years. A lot of it is about that PSL experience, and what you can learn there – not so much what in particular, but what the different participants took away for them.

Made aware by The Gift of Time, I had the chance to get a copy of Computer Programming Fundamentals – together with Mr. Leeds. This is the first book to mention software testing (written in 1958), and it held a lot of other interesting insights that still hold – half a century later. My favorite quote from that book is

One of the more dangerous occupational hazards in computing is the habit of working out a set of diagrams, formulas, and figures until some impressive statement like “twice as efficient” emerges.

In this regard the past fifty years didn’t change anything.

In the past year, I was able to read more about the background for the problem-solving leadership course in Jerry’s currently being written series on Experiential Learning. Together with the 4Cs from Training from the Back of the Room I found all of these lessons a fruitful combination for learners. Since then nearly no class has passed without me trying out different things from either of these sources.

Finally, just today I finished a piece which stood on my bookshelf unread far too long. The Psychology of Computer Programming was a great read, and I still digest most of the information. Although most of the lessons on psychology there might seem dated, it turns out not so much has changed in the programmers and the program managers. The only thing that has changed, maybe, is the name of the methods we use nowadays. From that perspective it’s a bit sad to see that not so much has changed in about half a decade in our industry.

That’s what I read so far. The only tragic thing about all these books is probably that the only book I have left to read from Jerry is The Handbook of Walkthroughs, Inspections, and Technical Reviews. From skimming the pages it seems to be more of a guide and FAQ. With the other 50 books on my unread shelf, I don’t know when I will start this one. Oh, and if you happen to know a good book from Jerry not in this list, I am open for recommendations.

What’s your story with Jerry’s books?

  • Print
  • Digg
  • StumbleUpon
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

13 thoughts on “My journey with Jerry Weinberg”

  1. He Markus,

    I own almost all the Jerry books you have. Currently I’m reading the Experiential Learning series and Computer Programming Fundamentals. The first chapters of this last book makes you wonder what we learned the last 50+ years in the IT industry. I had the same feeling when I read Computers and Society(1973) by Richard Wesley, Hamming which is a book you might like also.


  2. Hi Markus, interesting journey.
    Mine started where you ended! The first book I read was ‘The Handbook of Walkthroughs, Inspections, and Technical Reviews’, although to be honest it was more of a skim read. At the time I wasn’t aware of who Jerry Weinberg was but I was impressed by the book. I became aware of him through the ‘Perfect Software’ book, Michael Bolton said he would buy me a copy!! (around 2009 I think – before the cartoon tester), I was so impressed with his enthusiasm of the book and his generosity I went out and bought the book myself – I’ve not looked back since. I’ve read a few more but I have a long way to catch up to you and Ruud.
    The last book I read was ‘technical leader’ in late 2012. I am now reaping the rewards from reading and applying some of the lessons in the book :)


  3. Impressive just to start to comprehend the books and knowlegde Jerry created.

    I haven’t read any books so far but I will perform: @books_to_read << @library[:author]["Gerald Weinberg"]

    Just started to read “Principles Of Software Engineering Management” by Tom Gilb dated 1988. Seems like nothing changed…

    @Markus: are you aware of the work /books of Tom Gilb? Seems to be on the same page with Jerry…

  4. Thanks for your interesting blog post – internet moves fast so I don’t know if my comment will be read.

    My favorite book is “Secrets of Consulting”. I read it in the 80’s in my early 20’s and reread it 20 years later after becoming a consultant. To my amazement, I had internalized the rules so well that I thought they were my own ideas! Talk about successful consulting!

    Perhaps a book you might like to take a look at is Exploring Requirements: Quality before Design. I have found it a truly remarkable book, very deep insights, very thought provoking.

    I was fortunate to attend the PSL of 2008 in Uppsala and it reaffirmed my learning from Gerry. I also attended the AYE-conference of 2005.

  5. The first three ICT books I read (if I remember correctly) were a Fortran IV manual (at a university course), Technostress and Jerry’s Psychology of Computer Programming — to understand what this new computer world was about– all in 1983. Then there was a delay for 20 years, until some testing folks mentioned him, and I started buying all his books. Photo of the bookshelf (a couple missing book are at workplace):

    All are good, and more importantly, show unique viewpoints lacking in all other contemporary literature.

  6. Hi Markus,

    Thanks for sharing. It’s an interesting journey and I’m glad that you went that far.

    It’s a shame that I haven’t read any book from Jerry yet. I definitely pick one.

    Do you have any Jerry’s book in book to recommend for a tester to start with?


Leave a Reply

Your email address will not be published. Required fields are marked *