The Personal Software Process:

An "ego-centered" improvement paradigm

Daniel M. Roy

(STPP - Software Technology, Process and People)

(Visiting scientist, SEI)

Abstract: Vic Basili describes the evolution of software engineering in these terms [Basili-89]:

`We have evolved from focusing on the project, e.g. schedule and resource allocation concerns, to focusing on the product, e.g. reliability and maintenance concerns, to focusing on the process, e.g. improved methods and process models'

It is argued that the next wave of software engineering improvement activities will be based on a People-centered paradigm focusing on the individual pride and measurable self improvement that can be qualified as "ego-centered". Perhaps the most promising such paradigm, Watts Humphrey's Personal Software Process (PSP) is summarized and its advantages and limitations are listed. The evolution described by Basili is also compared to that of the management techniques as summarized in Weisbord's book 'Productive Workplaces' (from Taylor to Lewin to McGregor and to Emery/Trist and beyond). The PSP is shown to include some but not all of the elements necessary for 'Organizing and managing for dignity, meaning, and community' [Weisbord-88] at the workstation.

1. The Personal Software Process

The personal software process (PSP) was developed by Watts Humphrey to indoctrinate students (in university and industry alike) in the use of large scale methods based on the CMM. To quote Watts in [Humphrey-95], the PSP...

`... scales down industrial software practices to fit the needs of small scale program development. It then walks you through a progressive sequence of software processes that provide a sound foundation for large-scale software development'

The PSP course leads the student to the gradual application of software engineering discipline through a set of 15 assignments (10 programs and five reports and a report development process). Process issues are gradually introduced by leading the student through a set of 7 upward compatible processes (fig. 1).

For each assignment, the PSP student plans his/her work, enacts a well defined process, building the product while gathering data, performs a post mortem, and analyzes his/her performance. This analysis sheds some light on process deficiencies and other weaknesses, yielding some next goals for improvement.

Figure 1: Introducing the PSP

This paradigm is strikingly similar to that of the experience factory implemented so successfully at the Software Engineering Laboratory [Basili-94]. Perhaps, the PSP can also be seen as a downscaled experience factory, as an “experience workshop” (fig. 2).

Figure 2: The PSP: Downscaling the experience factory?

Like with each project in the experience factory, each PSP exercise embodies a specific set of improvement goals. The student derives a plan to achieve these goals and then executes the plan. All along the student collects data (such as time spent by process phase, defects injected and corrected, etc.). Finally, a post mortem is performed at the end of the exercise. Lessons learned are contributed to a private equivalent of the experience base (PSP data, reports, process elements) to feed the next cycle of improvement.

2. Some PSP results

When I took the PSP as one of Watts’ student in 94 I felt that having to gobble up nearly one new process every two weeks was like having to woof down a gourmet feast at a fast food pace. Probably in great part because of the world class cook involved, I resolved to savour every bite. I decided to do what I never was able to do before in my programming career: doing it right, consistently, right from the start, putting pride first. All my previous efforts studying methodologies, learning Ada, and the CMM, and the experience factory too; all that came together for me in that course. The PSP made me really taste these concepts. They truly became part of my own practice not because Watts had said so, but because I had gained a better understanding by trying them for myself and I had seen their positive impact on my very own data. That was my first and most important result. It convinced me that true improvement and indeed, any real transition, had to be “ego-centered”. Now I really understood Deming’s points 12a&b about pride of workmanship.

The measurement framework of the PSP made me realize that I was injecting a high number of defects in my software products. Pareto and other analysis revealed that I was relying too much on the power of my Ada compiler. I treated it as my “review assistant”. My technology was ahead of my process. By applying the PSP inspection techniques and by no longer trusting the quality of my software to a tool, I reduced my defect injection rate by a factor 4 in the 6 months I took to go through all PSP processes (figure 3)

Figure 3: Curtailing defect productivity (personal data)

As a teacher of the SEI “Train the Trainer” course for the PSP, I later saw similar results even though the students barely had time to “digest” the process notions that were hurled at them day after day during the grueling three one week periods (separated by a month) of this course format.

The course I taught at the Lawrence Livermore National Laboratory (LLNL) as a consultant from August 95 to February 96 consisted of 2 day visits every three weeks or so. During each visit, I presented the latest class results, offered two PSP lectures, discussed the results of the previous 2 exercises and assigned the next two. Most of the time at the site was devoted to one on one coaching, a crucial “ego-centered” element in the successful transition of the PSP in current practice. This format accommodated the day to day assignments of the LLNL engineers but it is typically judged too long and too expensive by private industry.

Results from the class however, seem to show that education may be much cheaper than the alternative. Figure 4 shows the defect removal effectiveness of design reviews, code reviews, compilation, and unit test for all the exercises of the PSP and for all students. The data shows that reviews are typically 2 to 4 times more effective than test in removing defects. Typically for each defect found in test, another defect reaches the customer in the field where it is most expensive to fix (costs of thousands of dollars per defect in the field are common). Unfortunately data on error rates and cost per defects are hard to obtain in level 1 organizations. Some of my students at LLNL have started to gather this kind of data for themselves and for their team, on the job.

Figure 4: Reviews vs. test

In the same vein, figure 5 shows an average reduction by a factor 6 in the number of defects found in test by my LLNL students.

Figure 5: Reducing defects found in test

These excellent results were not obtained at the expense of productivity. Figure 6 shows that even though average productivity did go down at first, as expected, it was back to its original level (even a bit better actually) by the end of the course.

Figure 6: Productivity inches back up

A less measurable result of this first commercial offering of the PSP at LLNL was the noticeably increased quality mindset of the students. At the beginning, issues discussed during coaching sessions dealt with the product and the details of programming techniques. By the end of the course, we were truly debating process issues (such as how to improve design inspection yield or the accuracy of project size estimates).

On the negative side, it is clear that not all engineers will have the open mindedness of my LLNL students who completed the course. There was little incentive to complete this course, no expected reward of any sort, and even the clear disincentive of job pressure and colleagues skepticism. My experience with Ada had prepared me well for all this. Class started with 12 students officially registered. This climbed to 18 after the first lectures (curiosity, fixed price, and entertaining speaker style, I guess). When attendees realized that real hard work was involved however, we quickly went back down to 12. Then, two key leaders decided to redesign the PSP on the fly for me, starting with dropping the exercises. I declined their help and I lost their entire team of 5 students. Sometimes, egos can get in the way of even the best ego-centered paradigm. To their credit, two student from this team continued to come to the lectures and nearly finished the exercises but had to drop out under mounting job pressure. Figure 7 shows the kind of mood swings that is typical in a PSP course.

Figure 7: PSP transition scenario

In light of this experience I believe that the way Watts taught the PSP at CMU was the best way to teach it (one lecture and assignment every two weeks). To accommodate the need of industry for reduced training cost, I do not see any alternative but to reduce the scope. Controlled experiments (a la Basili) should be undertaken to compare results after teaching the PSP in two installments (introduction followed later if desired by an advanced course) or even in four parts (PSP0, 1, 2 and 3). Time and field data will tell where the optimum is. The SEI has developed a two week version of the course and has already offered it successfully in industry.

3. Back to the future

To get a feel for where the PSP is heading, it may be interesting to compare the evolution of the software profession with that of others. In his marvelous book on the evolution of industrial organizations [Weisbord-88], Marvin Weisbord sheds a brilliant light on a possible future for our field (figure 8). Starting at the turn of the century with Frederick Taylor we have the myth of the omniscient guru, the expert/hero, fighting fires one at a time. In the 50’s, participative management and McGregor’s Theory Y made everyone fight the fires in teams. The next development occurs when experts start looking at the entire system to prevent fires from occurring in the first place. This is followed by a collective study and resolution of the same kind of problems (third wave management).

Figure 8: The evolution of industrial organization

Could we be following the same evolution? From the guru/artist of the past to chief programmer teams, to process experts and SEPGs, to ... generalized PSP? Weisbord says it beautifully:

‘Informed self control, not close supervision is the only way to operate new technologies.... Knowledge and skills can’t be pumped into people the way traditional schools have done it. They can be mastered only by applying theory directly on the job, to real problems, here and now. That requires the learner’s direct involvement. Even Taylor knew that. Moreover, the future of democratic values - dignity and worth of each person, free choice and free expression, social responsibility coupled to personal opportunity- depends on what we do today. Lewin understood that. We better fight for the integration of social, technical and economic change. Otherwise, we surely will put ourselves on the losing side of the knowledge revolution.’

Weisbord refers to Kurt Lewin, the visionary German born Jewish psychologist who was dreaming of a democratic Germany and of liberating Women in the 1900’s. Lewin had an incredibly productive life giving us force field analysis, T-groups, change theory (unfreeze/refreeze) and the learning organization, among other things. In Lewin’s learning organizations, People do by learning and learn by doing. There is recursion here, because to really understand a complex system, you have to work within it, experience its weaknesses and personally commit to your individual share of the needed improvement. This is what I mean by “ego-centered” improvement paradigm.

Can all this be done with the PSP? Not yet. The missing dimension is that of team interaction. I can’t wait to see Watts’ manuscript for “A team-based approach to disciplined software engineering” (I made this title up). This is the greatest challenge and to me, this is the future of the PSP.

Kurt Lewin left us too early, succumbing to a heart attack in his prime. His last words laid out the challenge ahead for organizations and individuals alike:

‘On the last day of his life, Lewin talked by phone with Ronald Lippitt about how unfortunate was the “American cultural ideal of the ‘self made man’, and ‘everyone standing on his own feet’, a notion as tragic as the initiative-destroying dependence on a benevolent despot. To Lippitt, he said what might be a benediction for leaders everywhere, especially in a time of fast change and dramatic new technologies. “We all need continuous help from each other. Interdependence is the greatest challenge”.’ [Weisbord-88]

4. Bibliography

[Basili-89] Victor Basili, `Software Development: A Paradigm for the Future’, Proceedings of the thirteenth Annual International Computer Software & Applications Conference, Orlando, FL, September 20-22, 1989.

[Humphrey-95] Watts S. Humphrey, `A discipline for Software Engineering', Addison Wesley, 1995.

[Weisbord-88] Marvin R. Weisbord, 'Productive Workplaces - Organizing and managing for dignity, meaning, and community' Jossey-Bass, 1988.