Title: A Discipline for Software Engineering
Author: Watts S. Humphrey
Publisher: Addison-Wesley
Publication Date: 1995
Pages: 816, hardback
ISBN: 0-201-54610-8
Price: $47.29A Discipline for Software Engineering is about improving yourself as a computer programmer. If a large portion of your income comes from programming, I urge you to look at this book. Watts S. Humphrey is best known for his work with the Software Engineering Institutes Capability Maturity Model for large software producers [1] . He has shifted his focus to helping the individual programmer with his Personal Software Process (PSP).
This book is for (as P.J. Plauger says) "enthusiastic programmers" [2] . These programmers enjoy the challenges of software and take programming seriously. Humphrey says that his book is for people wanting to move from being computer programmers to software engineers. This may sound a bit elitist, but its not really. This book is for programmers striving to write better software (fewer defects) in less time, predictably. Almost everyone wants that. Of course, not everyone will swallow Humphreys prescription, which is a big dose of discipline. Thus, this book may overwhelm recreational programmers those who program for the enjoyment of learning and as a constructive way to pass time. Most important, this book speaks to programmers who are willing to change how they write software if measurements show they should change. If change is unacceptable to you, save your money.
The Personal Software Process
The PSP is a systematic course that concentrates on measuring what you do, analyzing the numbers, and then doing what works. In some ways it is a personal metrics program. Heres how it works: First, record how long it takes to do everything. Then, examine the numbers, see what techniques save or waste time. Keep the good, and throw out the bad. This is a simple idea, but doing it is not so simple.
The PSP is about process not product. To understand the distinction, consider Steve McConnels Code Complete [3] . This book shows examples of good and bad programs (products). By contrast, Humphrey shows that performing certain steps (processes) will help produce good programs. (However, the standards in books like McConnels are a key part of what Humphrey requires in the PSP, so hold onto those standards.)
The PSP focuses on defects. Finding and correcting defects consumes more time than anything else in software development and maintenance. The PSP tries to discover where we inject defects into software and how to prevent them. The hard part of the PSP is measuring and analyzing different programming activities. Most of us have never done that, and if youre like me, you want to scream "Im a programmer, not a bureaucrat."
Humphrey uses statistics heavily (so much so that he includes a short course on statistics as an appendix). The statistics lessons are very dry and could cause a casual reader to put away the book. The challenge is to remember the purpose of the statistics they show what works. After completing a dozen personal projects using the PSP, you will have a historical database of projects at your disposal. This database will show which techniques work and how long it takes to do tasks. You can use this database to make reasonable estimates for future tasks and justify those estimates.
The PSP leads you through the steps of planning, designing, coding, compiling, testing, and producing a postmortem for each project. (Hold on, there is room for iteration later.) You estimate how long each task will take and record the actual times. The PSP focuses programmers on defects by requiring them to note every defect found, when they found it, when they injected it, and the time required to remove it. Humphrey prescribes designing software and reviewing the design before coding. He also suggests printing the code and reviewing it closely before compiling.
Humphrey teaches this process in seven steps from PSP 0 to PSP 2.1. This is a wise strategy because PSP 2.1 (described above) is alien to most programmers. Few of us could change from our current practices to it in one leap. Humphreys steps ease you into the discipline gradually, and let you see for yourself that the PSP works.
I promised we would get back to iteration. PSP 2.1 works for projects that require tens of hours. The programmer should break bigger projects (PSP 3.0) into several PSP 2.1-size jobs and do them one at a time. He then can add each piece to the kernel of the project as that piece is finished.
A PSP Training Manual
Humphreys book is both a training manual for practicing programmers and a text for senior or graduate level college courses. Its 14 chapters and four appendices teach the PSP with examples and exercises. The book represents the authors accumulated experience, having taught the PSP for several years in industry and colleges. Over the years, hes modified the PSP to account for what he learned in teaching it.
Humphreys experience keeps this book practical, not theoretical. Humphrey gives results from dozens of his and his students personal projects. The numbers show which practices are effective.
The reliance on measurement is the books strength. Many such books say, "I think my method should help you." Humphreys book says, "These are the experiences of programmers. These methods reduced defects, reduced development time, and allowed programmers to predict when they would finish."
A Discipline for Software Engineering is a workbook. Its not the kind of book you just read from cover to cover and then try a few of its suggestions. Humphrey discusses principles and enforces them with homework assignments. Learning and benefiting from Humphreys experiences requires doing ten to nineteen homework problems (five to ten hours each). A floppy disk containing templates and spreadsheets for the exercises is available from the publisher for $15. I recommend that you get the disk if you are going to do the exercises.
I worked through the PSP, and Humphreys methods are effective. That is a bittersweet statement. I always thought I was smart enough to sit at my keyboard and write programs off the top of my head. Unfortunately, the measurements and analysis of my own projects proved otherwise. I enjoy just writing programs off the top of my head, but that is not the most efficient way to develop software. I never thought I would endorse printing and reading code before compiling, but it works. Maybe I can do fun programming the fun way and serious programming the right way.
If you write programs for a living, you should work through Humphreys book, analyze the results, and decide for yourself how youll write software from now on.
References
[1] Watts S. Humphrey. Managing the Software Process (Addison-Wesley, 1989)
[2] P.J. Plauger. Programming on Purpose II, Essays on Software People (Prentice-Hall, 1993)
[3] Steve McConnel. Code Complete (Microsoft Press, 1993)
Dwayne Phillips works as a software, systems, and computer engineer with the United States Government. He has a Ph.D. in Electrical and Computer Engineering from Louisiana State University. His interests include computer vision, artificial intelligence, software engineering, and programming languages.