“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:
the ability to observe what’s happening and to understand the significance of your observations
the ability to act congruently in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide
the ability to understand complex situations so you can plan a project and then observe and act so as to keep the project going according to plan, or modify the plan.
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.
1. Barry W. Boehm, Software Engineering Economics, (Englewood Cliffs, NJ: Prentice-Hall, 1981), p486.
2. Anonymous, The Thinking Machine, (Time, 1950) 54-60.