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.
The second problem is that, when developers are not truly committed to their plans, they will frequently agree to include “minor” changes that seem easy to implement and attractive functions without even telling the managers.
When teams make their own plans as described in the answer to question 1, these problems are typically resolved. The members know how much work they planned and can estimate what even small changes will involve. Then they are better able to recognize the costs of even minor changes and are unwilling to take on added work without some plan adjustment. Even when teams make their own plans, the manager must insist that no change is free and that the impact of every change must be estimated, planned and approved before it can be implemented.