Watts Humphrey headed the IBM development team that introduced the first software license, and he later served as its director of programming and vice president of technical development. He is a fellow of the Software Engineering Institute and the Association for Computing Machinery, as well as a recipient of The United States Patent and Trademark Office’s National Medal of Technology.
Accolades and accomplishments aside, he’s also made his share of mistakes, and from his decades of experiences, he learned hard lessons about how software projects should be managed, how to manage teams, his bosses and himself. Humphrey recounts those experiences in his recent book, “Reflections on Management,” which is the subject of his interview with SD Times.
SD Times: In your book, you discuss at length the impact that poor planning has on quality. How does a programming manager know whether they created a quality plan or not?
Watts Humphrey: A good plan must meet four requirements: It must be in sufficient detail to guide the work; it must accurately represent the costs and time required to do the work; it must be supported by sufficient facts and data to be convincing to senior management; and it must be owned by the development team and represent what all of the members are personally committed to accomplishing.
Since most plans are made by the managers and not the developers, they cannot meet requirements 1 and 4 and rarely meet requirements 2 and 3. These requirements can be met consistently when teams make their own plans. However, today’s software developers typically don’t know how to make plans and don’t believe that they should. They generally believe that planning is something that managers do. Changing these attitudes and skills is the key to good planning, and the Software Engineering Institute has developed the Team Software Process to guide developers and their management in doing this. I describe how the TSP does this and why this method is so effective in some of my books and papers.
You stated that blaming changes in requirements for failure is just an excuse for bad management. How can a programming manager avoid requirements creep, and how is the belief that changing requirements endanger projects an excuse?
Requirements creep can only be avoided by insisting that every requirements change, no matter how small, be supported with a plan to implement the change, and that management and the customer must agree on the extra time and resources required. Actually making plans for every small change, however, presents two problems.
First, few plans are detailed enough to permit this level of dynamic replanning. Then the costs for the added work are hard to determine and even harder to justify. The manager then typically loses the resource debate and ends up eating the added work.