Note: This is a personal review of a tutorial. It is not an evaluation of whether this is appropriate for MIT now, or at any time in the future. This is offered PURELY in the interest of information transfer. I have NOT tried to duplicate the entire tutorial here, only to give a flavor of the main topic.
If any of this piques your interest, let me know, and I will share more of the tutorial materials (or the book) with you.
November 2, 1996 Tutorial. "Improving Personal Productivity." Part of the ACM's Greater Boston Chapter's Professional Development Seminar series, held at Northeastern University.
The tutorial was led by the inventor of the PSP, Watts Humphrey. Mr. Humphrey has been associated with the Software Engineering Institute (SEI) at CMU for a long time, and was one of the architects of SEI's Capability Maturity Model (CMM). Prior to his association with SEI, he spent many years at IBM, and has some sort of past MIT affiliation as well.
He has written a number of books. The PSP is described in detail in "A Discipline for Software Engineering."
The PSP may be best explained in terms of the CMM. The CMM is a five-level model where level 1 indicates initial, random approaches to software engineering practice, and level 5 indicates a very well-documented, managed, repeatable, and reliable software development process. Humphrey describes PSP as "what you get when an individual engineer is working alone at a CMM level of 5."
It's worth noting that some resistance to CMM introduction has been on the basis of its being too large, an enterprise-wide kind of approach. The PSP is an attempt to "down-size" or "personalize" the process. But the term "personal" is a bit misleading. It relates to the target of the process improvement, an individual engineer. It does not constitute an endorsement (in fact quite the opposite) of hacker-ish, or artisan style, software development.
The PSP paradigm is similar to the CMM. It consists of these process improvement principles:
To date, resistance to introducing PSP in organizations has come from two different sources. First, from engineers themselves. If individual engineers are not willing to take this process-oriented approach to their work, PSP will fail. Second, from management. If management does not allocate time for taking this approach, and asking for, and managing according to, this approach, engineers will not allocate time to keeping/analyzing the date, PSP will fail.
Like the CMM, the PSP is a multi-level model.
At PSP0, engineers learn to use a basic personal process, to gather data on their personal work, to measure the size of their products, and to gather baseline data on their methods.
At PSP1, engineers can use their historical data to estimate the sizes and development times of their products, and to use statistical ranges in these estimates.
At PSP2, engineers can measure the efficiency of their defect removal methods, and to use various process quality measures.
At PSP3, engineers learn how to adjust their process for different kinds of work.
The PSP is best "learned" in a course/workshop kind of environment, which SEI (and other third parties) offers. Students use PSP process principles while they are writing 10 different programs, starting with a base of their current work methods. Then, through systematic improvements, by keeping track of what/how they're doing while writing these programs, students learn the value of the process based software development. By the end of the course, students know how to:
Mr. Humphrey's research data shows that most of the measures and estimates are highly dependent on the individual engineer, and that no other single variable, experience, language, etc. are useful predictors of size, resources, schedule, defect rate, etc. Therefore, it is his contention that the data collected is truly personal data. He contends that this data should be gathered by the individual, for use by that individual, and not shared with managers, or others.
Armed with their own personal data, engineers should be able to respond with professional estimates, not guesses, to questions like:
There have been cases where companies felt that they wanted to collect all of this personal data. This was a chilling effect on PSP as these data were thought to be used for performance measurement, promotions, raises, etc.
In PSP, defects are the basic quality measure. Therefore, low
defect content is an essential prerequisite to a quality software
process. To achieve this, Humphrey makes a strong case for NOT
relying on downstream activities to "fix" the problems
of upstream activities. In this own words, "if you want a
quality product out of test, you must put a quality
product into test." This is based on his
research data that testing removes only a fraction of the defects.
Similarly, "if you want a quality product out
of compile, you must put a qualify product into
compile." This leads Humphrey to a major emphasis on NOT
relying unduly on compilers to "review" code. His belief
is that compilers are for generating object code, not for checking
syntax. To check syntax, he believes that professionals need to
privately review their work, and to try and find all defects before
they compile and test.
November 6, 1996