"Weinberg addresses more clearly the form and essence of quality that we software people worry about... I can't imagine a better way to help change the thinking process in your organization than the wide-scale distribution of Jerry Weinberg's wonderful book." - Ed Yourdon, American Programmer
(translated into Japanese, Portuguese, German)
The first volume in a series designed for managers who wish to help their organizations deliver and maintain quality software. This volume is devoted to the thinking processes that characterize high-quality managers, and is for all those people who wish to improve the quality of their efforts as software managers.
Order now from Dorset House Books!
Reviewer: James Bach from Front Royal, VA (Source: Amazon.com)
This book holds a special place in my heart. It's the first technical book I ever read in one sitting.
I've been in the software business since 1983. By the time I encountered Quality Software Management in 1992, I was thoroughly cynical about books about software project management. By and large they were, and still are, preachy tomes that quote unverifiable statistics and make dubious claims about "right" and "wrong" processes. Grow up, guys!
Jerry's books are different, and this is my favorite of all of his books. As I read QSM, I didn't feel preached at or condescended to. I felt like, for the first time, someone was offering me ideas for coping with the very difficult problems that face those of us who work on projects where we don't have enough time, enough information, enough skill, or enough money to do a perfect job of anything. Given our limitations, we have to make tradeoff decisions in light of the best understanding of cause and effect we can muster. That's exactly what my organization was trying to do, in '92, when we were competing and winning against Microsoft (oh, they eventually beat us by hiring away the top third of our team, but that's another story). We just thought of ourselves as pragmatists, but when I read QSM I realized that our approach was also scientifically sound.
Looking back, I see QSM as one of the handful books in this field that actually helped me to become more expert at my job, and it's the first book I suggest to anyone who is serious about software quality assurance or software project management.
Get it and read it.
-----
A most enlightening introduction to quality., June 13, 1998
Reviewer: Ned Hamson from Cincinnati, Ohio (Source: Amazon.com)
I am not a software developer. When I stumbled across Gerry's book, I soon realized that I had found a hidden treasure. It contains within it the best definitions of quality that I have ever read. And he has a great sense of humor that helps make the lessons and insights you will get from the book easier to take. PS: His other books are equally great and should be read by software folks, as well as everyone else. Ned Hamson, Senior Editor, Association for Quality and Participation.
-----
Examine how you think about software development, May 13, 1996
Reviewer: A reader (Source: Amazon.com)
Why is software development so often plagued by crisis? Weinberg helps the reader step back from developing software and examine the dynamics and patterns of software creation. By discussing patterns of quality, patterns of managing and patterns of software faults, the author shows that quality software begins with keen observation and clear thinking about software development. The text is extremely thought-provoking and is spiced with anecdotes drawn from decades of software experience. When my software team considered the book in a study group last year, our insight into our efforts and understanding of each other took a leap upward. Highly recommended
-----
A Review by Johanna Rothman, from her newsletter, Reflections
I originally read this book and used it while I was a manager at a Boston-area company. I was trying to understand why my quality initiatives were sometimes effective and sometimes not so effective. I bought the book because I was sure there was something in my system (the company, the other employees, me, the products, etc.) that was preventing me from succeeding. I hoped to figure out the issues by reading the book.
The book is divided into five sections: "Patterns of Quality", "Patterns of Managing", "Demands that Stress Patterns", "Fault Patterns", and "Pressure Patterns". Each section has a number of chapters that examine different systemic aspects of the specific issues.
In the "Patterns of Quality" section, Weinberg challenges our assumptions about what quality is, how to obtain it, and how to recognize how to change it. For those of you who are intimate with the SEI (Software Engineering Institute) CMM (Capability Maturity Model), this section provides compelling reasoning about the model, and about how dangerous level 2 can be to an organization.
The "Patterns of Managing" section was truly eye opening for me. I had been working on a measurement system at the company, and had been spectacularly unsuccessful obtaining useful metrics. I thought we needed these measurements so that we could understand what worked for us, and what needed to change. This section gave me a new understanding of how other people see the organization and their roles within the organization.
"Demands that Stress Patterns" discusses what happens in real organizations with real customers and real products. Jerry has a number of ideas about how to keep the development organization working productively.
"Fault Patterns" discusses different types of defects and how they occur. In addition, Weinberg examines what software faults and how the organization deals with them means to how the people work.
"Pressure Patterns" looks into managerial behavior and why managers lose patience and feel helpless.
I learned more about my behavior than I expected! I had originally thought I would learn about why my peers were working in a way that was unhelpful. Once I started reading the book, I realized that I could influence the way they worked so that I could improve our quality practices and they could succeed at getting their projects shipped. Since then, I have used systems thinking in my work, and I highly recommend that other software managers do so also.
I highly recommend this book to all managers who work with software organizations. .
"Poor management can increase software costs more rapidly than any other factor." - Barry Boehm (1)
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." (2) 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 certain did. Since that day when I became one of those dreamy-eyed young "question-answerers" (the word "programmer" hadn't yet been coined), I have learned that there are three fundamental abilities you need if you're not to lag farther and farther behind:
All three abilities are essential for quality software management, but I don't want to write a large, imposing book. Therefore, like any good software manager, I've decomposed the project into three smaller projects, each one addressing one of these three fundamental abilities. For reasons that will become clearer in the book, I am starting with the third ability-the ability to understand complex situations.
In other words, this is a think book. Its motto is the same as IBM's, because it's my way of paying back IBM and others for the wonderful things I've received from 40 years in the software business. I can imagine no finer gift than helping someone, as others have helped me, to think more effectively about a subject that is so important to them personally, as well as to the world.
2. Anonymous, The Thinking Machine, (Time, 1950) 54-60.