I recently took the Personal Software Process (PSP) training governed by the Software Engineering Institute (SEI). The PSP is the process-for-the-individual that supports the Team Software Process (TSP). Both were created by the late Watts Humphrey. While it was relatively fresh I thought I’d jot down some thoughts about the PSP as well as some advice to the SEI.
There are several key ideas in the PSP that are extremely powerful and compelling:
- Proxy-Based Estimating: The idea here is that when estimating you categorize “chunks” of work into various sizes and use your historical performance data as a “proxy” for the effort estimate. This idea alone is worth the price of admission, and if you work in an organization that relies more on up-front planning than on continuous refinement of schedules, this may be the only way to make it work over time.
- High quality results: The PSP as a whole very much focuses on the notion of the cost of quality. Loosely translated, the idea is that high quality software is actually cheaper to produce in the long run because the cost of fixing errors is so high. Classic Deming, but difficult to argue with if you’ve ever seen a project buried under the weight of its defect backlog.
- Using Earned Value (EV) to Track Progress: EV is a staple of standard project management procedures (refer to the PMI if you’re interested), but it entirely relies on starting with good estimates. The simplest form of EV is to simply mark each item in the schedule as only “done” or “not done”; none of this 72.4% complete nonsense. But in any event, knowing where you are in a project is unarguably useful.
Disciplined processes such as the PSP take a great deal of heat from the hacking community, or the toy-problem community, but I think you need to look at it with an honest appraisal of how effective your personal way of developing is; how accurate are your estimates? do you actually break down your estimates to items that are sized such that they can be estimated accurately? how buggy is what you release to QA? or to the customer? What is the cost (both to you and the company) of the bugs that get that far? Ruthless honesty is uncomfortable here, so you may want to add a little ruth back in just to make it palatable…
The PSP doesn’t deal with many critical issues such as scope and requirements creep — these are left for the Team Software Process. Still the PSP is worth checking out, if for no other reason than to broaden the scope of how you think about doing a project.
However, the SEI seems to be bent on some key barriers to acceptance of the PSP by a wider community. In order to appreciate the valuable things about the PSP, there is a lot you have to look past:
- Pedantic Presentation: The PSP process is presented as a long list of things you must do, that you simply cannot do without in order to use it. This is in sharp contrast to methods such as Agile that provide a toolbox approach, and are much easier to adapt to. Further, much of the PSP book is devoted to working through the math that is used in adapting the estimation model — which is fine but gets in the way of the important material.
- Outdated in Many Respects: The PSP insists on doing software inspections on paper, multiple pass inspections with checklists, logging time for the “compile” step, and other steps that are quite simply just grossly out-of-date. Even the insistence on doing inspections on paper — though supported by some empirical data — will simply never be widely adopted at this point. The PSP also does not incorporate newer thinking about unit testing or test-driven development, nor does it make a distinction between manual and automated tests. In many ways, it’s like a little process island from the early ’80s…
- Defect Categorization is Weak and Poorly Defined: The PSP defines a “defect” as anything discovered after the fact that requires a change to an artifact, whether code, design docs, or whatever. This definition is just silly. A typo is not the same as a functional error. A defect found after release is qualitatively different than many/most defects found during code inspections (e.g. coding standard violations, typos, minor refactorings, etc). And although the PSP lets you classify “defects”, all the process quality metrics are based on raw, uncategorized defect counts.
- Copy-and-Edit is not Reuse: Finally, the PSP seems to view code reuse as simple copy-and-paste-and-edit. How to fold an active reuse program into the PSP or TSP is not at all obvious, and the oblique way the PSP does it is not useful at all. This may be, again, just another example of how outdated much of the PSP is.
Without addressing these problems in the PSP, I doubt that it will ever achieve widespread interest or acceptance as compared to, say, Agile or Lean processes.