, The Software Engineering Institute
Pages: pp. 71-75
When I started to develop SEI's Personal Software Process, I was both looking for new processes and methods and trying to satisfy my curiosity. I wanted to answer this question: Would process improvement principles work for individual software professionals? I had spent over 30 years in engineering and engineering management before I started working on software quality and process improvement. These methods worked for organizations and for large projects, but it was not clear how they would work for individuals, particularly those doing creative engineering work. While the principles seemed applicable, I was trained as an experimental physicist and thus needed to understand how a process worked at the atomic level before I could feel I really understood it.
During my early PSP research, I was surprised by the insight I gained from using a defined, planned, and measured personal process, not only for routine work, but for creative work as well. After completing my initial PSP research some years ago, I have devoted the ensuing years to getting these principles adopted by individual engineers, software organizations, and the academic community. The four articles on the PSP in this issue examine the topic from various perspectives, but the fundamental question they all address is essentially the same: How can process improvement help individuals be more effective while doing intellectual work?
PSP development is based in part on the quality management principles of W. Edwards Deming and Joseph M. Juran. 1,2 In a more general sense, these methods follow principles that Frederick Winslow Taylor introduced over 100 years ago. 3 Taylor invented what has been variously called task analysis, scientific management, or industrial engineering. He was the first to view manual work as something to analyze and improve, and the first to gather and analyze data to improve the performance of manual tasks. Peter Drucker asserts that Taylor's methods made factories possible and that they were largely responsible for the 50-fold increase in labor productivity over the last 100-plus years. 4
In his insightful book, Management Challenges for the 21st Century, Drucker describes the similarities and differences between manual and intellectual work. 4 The principal similarity is that both kinds of work involve sequences of tasks. Even though manual and intellectual tasks are significantly different, we can measure, analyze, and optimize both and thus apply Taylor's principles equally well.
The principal difference between manual and intellectual work is that the knowledge worker is essentially autonomous. That is, in addition to deciding how to do tasks, he or she must also decide what tasks to do and the order in which to do them. The manual worker commonly follows a relatively fixed task order, essentially prescribed by the production line. So studying and improving the performance of intellectual work must not only address the most efficient way to do each task but also consider how to select and order these tasks. This is essentially the role of a defined process and a detailed plan. The process defines the tasks, task order, and task measures, while the plan sizes the tasks and defines the task schedule for the job being done.
Besides Taylor's principles, the PSP also considers task selection, planning, and ordering. It shows engineers how to use a defined, measured, planned, and quality-controlled process to improve personal performance. When they use the PSP, engineers plan their work, measure the work as they do it, and when done, analyze the measures to improve their performance.
We use a course and a textbook to teach engineers the PSP methods. 5 The course guides software professionals through 10 programming exercises that demonstrate how to apply project, process, and quality management methods when writing module-sized programs. By completing the exercises and analyzing their data, the engineers can see how a defined and measured process helps them do better work. They cannot argue that the PSP methods do not work for them, because they can see from their own data that they do.
In the PSP course, engineers learn what a defined process is and how to use one. They learn how to make estimates and plans, what data to gather, how to gather data, and how to use data. They also learn how to plan, measure, and manage the quality of their work. The PSP is not only designed for writing module-sized programs, it also teaches general skills that software engineers can use in most aspects of their work, from the initial requirements and system design phases all the way through to final system test and delivery.
Because of the nature of the PSP course, the earliest evidence of its impact is from class data. 6-8 In using these data, we must know whether results are due to the course environment or the PSP material itself. Several published reports now show the PSP's benefits. One study showed that students' improvements during the PSP courses were large and statistically significant. 6 Two other articles showed that when engineers were PSP trained, their job performance improved substantially. 9,10 The four articles in this issue add to this body of evidence. These data come from multiple studies, multiple PSP instructors, industrial and academic courses, and a broad mix of languages and engineering environments.
One of the most important factors in improving worker performance is prompt and explicit feedback. 11-13 We designed the PSP to provide this as an inherent part of the process. In fact, PSP practitioners often cite feedback as the reason for their conviction that the methods help them. So it is fair to say that the performance improvement shown by the PSP is at least partly due to the feedback the engineers get from their own data. Thus, the most pertinent questions are, Are these results unique to PSP courses, are they general, and does the effect persist? So far, as the articles in this issue and other experience show, the answer to all three questions is yes.
The Green-Hevner article provides useful guidance on introducing almost any new technology. It shows how to improve the acceptance of new methods and indicates damaging actions to avoid. For example, they note that practitioners will readily accept and adopt methods that help them reduce the complexity of their working processes. Further, for intellectual work like software, people will resist any attempt to force changes in the way they work. Finally, even new and attractive methods can be rejected if introduced in the wrong way or at the wrong time. The key message here is that software professionals are thinking people; they resent being ordered to do almost anything. If they are treated with respect and have a say in the changes that involve them, the results will be more successful.
More specifically on PSP introduction, there are various ways to attack the transition problem. The approach taken by Marisio was to change the PSP process and training to better fit what the particular organization was willing to do. Although this approach has the advantage of initially overcoming user resistance, it has the disadvantage of allowing the desires of uninformed users to drive process design. Because users almost certainly do not have the training or experience to design a software process and its introduction method, poor results are likely.
Several other organizations have objected to the full 14 days of PSP training required for industrial introduction and have devised their own special four- to six-day courses. As Kamatar reports, when engineers receive only limited PSP training, they do not learn the methods sufficiently well to use them in practice. Similarly, several organizations have tried to use the PSP with little or no guidance or adaptation. While this has worked in two cases that I am aware of, generally the engineers soon stop using the PSP. The stated reasons were that the environment didn't encourage PSP use, management didn't support it, and the other engineers were not using it. Under these conditions, engineers generally find it difficult to continue to use the PSP.
We at the SEI have worked for the last five years on PSP introduction and have found results similar to those reported by Marisio and by Kamatar and Hayes. The training required is substantial, and organizations are often reluctant to make that large an investment. However, without proper training and support, the PSP methods generally will not be used. Where PSP introduction has failed, the fundamental problem has been that it was viewed as an engineering training program rather than as an organization-wide process change.
Since training is such an important part of PSP introduction, it would be helpful to know how much training is required. While developing and learning the PSP, I wrote 62 programs in Pascal, Object Pascal, and C++. I then developed a course to teach these personal-process methods to others. I had hoped that others would learn much more rapidly than I had, so I only used 10 programming exercises in the PSP course. To date, our data show that the full PSP course with 10 exercise programs has been effective in teaching both students and working engineers how to use the PSP. From available course data, however, it is also clear that the high rate of improvement during the course continues right up through program 10. Thus, additional exercises could be beneficial. Although some experienced PSP instructors have concluded that more exercises would help, we do not have data to support this conclusion.
At the opposite extreme, when engineers only complete six or seven PSP exercises, they generally do not learn the methods or use them afterwards. Perhaps most important, because partially trained engineers do not use the method properly, they cannot complete PSP learning on the job. However, as the three articles in this issue and others have found, even modest use of the PSP methods can be beneficial. 9,14
Learning the PSP process appears to be fundamentally different from the way people learn other topics. With programming languages, for example, introductory courses usually teach programmers enough so they can start using the language. Then they can continue learning the more subtle aspects of the language as they use it on the job. We need to identify the level of fluency required before engineers will properly use the PSP in practice. Then they would presumably become more competent with experience. While the critical point where learning will continue is likely to be different for different people, we at the SEI expect it will probably be at or very near the 10 exercise programs in the current PSP course.
Another factor tends to help people learn a programming language but not the PSP. After taking an initial language course, working engineers generally have no choice but to use that language in their work. With the PSP, they can always choose to revert to their previous practices. This is a key challenge of industrial PSP introduction and one of the reasons for the development of the Team Software Process.
Based on results to date, using a defined, planned, and measured personal process appears to offer many benefits. Assuming that further experience confirms these early results, we can expect the PSP to be widely adopted and used. From the experiments reported here and elsewhere, it is also clear that industrial introduction of the PSP will not be easy. To guide organizations through such a comprehensive change program and to facilitate industrial transition to and use of PSP practices, the SEI has developed the Team Software Process. 10,15-17 We at the SEI have concluded that a team-based training and introduction strategy is both easiest to implement and most frequently effective for industrial organizations.
Presuming that the demand for skilled software professionals continues to increase, the most appropriate way to introduce the PSP would be through the educational system, just as with other professional disciplines. Rather than having students first learn undisciplined practices and then unlearn them, we should introduce disciplined methods at the beginning of the curriculum. Some universities have started offering such courses, and preliminary results are promising. 18-20 While several universities are also teaching an introductory TSP course to student teams, no published results are available. Additional information on the PSP and TSP is available at www.sei.cmu.edu.
The article by Xiamong Zhong, Nazim Madhavji, and Khaled El Emam, "Critical Factors Affecting Personal Software Processes," examines the detailed behavior of the PSP process. The authors measured the performance of 53 students and used regression methods to identify the variables responsible for the productivity and quality results obtained. As far as I know, this is the first article to examine the detailed relationships among the many variables involved in software work. It demonstrates the opportunity for important research with students or professionals who use the PSP. For example, by conducting studies of design methods, review techniques, language features, or tool functions, we could better understand how to develop software processes, tools, or methods to improve the performance of working engineers.
Two of the articles address the PSP's use in industry. "An Experience Report on the Personal Software Process" by Jagadish Kamatar and Will Hayes shows that the PSP, when properly used, can result in substantial improvements. On the first reported project, Kamatar and three PSP-trained colleagues had only three system test defects for a product with 40,000 lines of code. Typical industrial system-test defect levels for such products range from 200 to 400. Kamatar also describes the feedback provided by the PSP data and how he used it to improve product quality and estimating accuracy.
"Applying the PSP in Industry" by Maurizio Morisio describes the introduction of the PSP to an industrial organization. The problems he encountered concerned training, process design, data privacy, paperwork, and data gathering. In addition, he faced a problem common to almost all technology transition efforts: management's unwillingness to interrupt projects for long enough to completely train the engineers. In addressing these concerns, Marisio significantly changed the PSP process and course. As a result, the engineers used part of the PSP methods and obtained only limited benefits. However, the experiment provided useful insights, and the modified process appeared to provide some benefits. At least the engineers seemed to like the process, and the organization continues to use it.
"The Successful Diffusion of Innovations: A Guide for Software Development Organizations" by Gina Green and Alan Hevner examines the introduction of innovative IT technologies, using the PSP as an example. The authors find, not surprisingly, that engineers are more satisfied with a technology and are more likely to use it when they have a choice in selecting it. Engineers also more readily accept technologies that improve their ability to predict the results of their work. In addition, the authors found that when programmers feel increasingly able to control the methods they use, their satisfaction and use of the methods actually decline. On reflection, this finding is consistent with PSP and the SEI's Team Software Process experience: engineers will readily accept and use a precisely defined process as long as it reduces workplace confusion and helps them do their jobs.
I thank Dan Burton, Noopur Davis, Will Hayes, Don McAndrews, Julie Mullaney, and Bill Peterson for their helpful comments and suggestions during the preparation of this article.