NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: December 1, 2003
This is the fourth and last in a series of columns about programming principles. The earlier columns discussed the principles that relate to programming requirements, software products, and the projects for developing these products. This column deals with people and the human aspects of the software process. While this is an enormous subject and no brief column could possibly do justice to the vast body of relevant knowledge, a few key principles are particularly important in determining the performance of software people and the teams on which they work.
While most people behave in reasonably predictable ways, software people are unique, both in their creative abilities and in the nature of the work they do. Software professionals are among the brightest people on earth. Most of us got into this field because we were excited by the thrill of working with a challenging and very special technology. However, the problem many of us face is that the environment in which we work rarely supports and motivates consistently high-quality creative work.
In this column, I discuss the factors that govern the performance of software professionals, the most effective ways to obtain superior performance, and the key issues to consider in motivating and guiding teams of creative professionals.
Much as in other professions, the performance of software people is governed by four things.
These four governing factors form the basis of the four people principles discussed in this column.
This seems to be such an obvious point that it is hardly worth discussing. However, it is important and often overlooked. If the members of a development team are not intimately familiar with the job their product is to perform and the way the users of that product will use it, the project will almost certainly be troubled and the product will likely be a failure. If you can’t put users or people with user experience on your development team, at least ensure that the team has ready access to people with such knowledge. To produce quality products, a close and cooperative relationship with such people is essential.
While software developers usually get extensive training on tools and methods, they generally get little or no guidance on their personal practices. This is not true of any other sophisticated technical field. Chemical engineers are not born knowing how to conduct experiments, analyze the composition of materials, or follow sound laboratory practices. Doctors learn their profession through extensive training, by completing several years of internships and specialty studies, and by mastering the methods that their predecessors have found most effective.
In software, we have yet to learn the truisms that some methods and practices are more efficient and cost effective than others and that the cost and quality of the products we produce is governed by the practices we use in developing them. Today, on many projects, the developers do very similar work but their personal practices are very different. I have studied such teams and found that even developers who do similar work use different methods and, what is worse, they are generally unaware of the methods their peers are using. Except for occasional help with problems or complex tools, most software people work largely alone and are unaware of how others work or the best ways to do each of their tasks.
If every scientist had to personally discover Bernoulli’s principle, develop Maxwell’s equations, or invent calculus, we would still be in the dark ages. The explosive growth of science and engineering didn’t start until people defined their practices, measured their work, and communicated precisely. This allowed others to repeatably produce the same results. The essence of science and engineering is learning from the experiences of others. Until we build a body of professional software practices and teach new professionals to consistently and properly use these practices, programming will remain an unsatisfactory craft that produces defective, insecure, and even unsafe products.
We now have data on several thousand programmers who have taken the Personal Software Process (PSP) course as well as data on over 100 Team Software Process (TSP)teams that have been launched*. It is now clear that developers can learn and use highly effective personal practices and that, when they use these practices, they produce much better work than they ever did before. In a recent study of 20 TSP teams that provided data on delivered product-defect levels, these products had 100 times fewer defects than average industrial products and 16 times fewer defects than typical products produced by CMM level 5 organizations . In most cases, these were first-time TSP teams. Since personal and team performance typically improves with experience, we can expect even better performance in the future.
The obvious problem with requiring that developers use the best practices is in determining what the best practices and methods are. However, the reason that the PSP and TSP are so effective is that they provide developers the tools and methods they need to make this decision for themselves. With the PSP, professionals learn how to follow a defined process, how to modify that process when they need to, and how to measure and plan their personal work. By using their own data, developers can see what methods work best for them, and they can make informed decisions about how to do their work.
Similarly, when TSP teams are launched, they examine the job that they have to do and consciously decide on the best strategy, process, and plan for the work. While this may not seem to be the best possible way to do the job, it is the one that the team members think would be best, and these are the only people who know their personal skills, abilities, and interests; the work that must be done; and how they can best work together as a team. So, while there may be theoretically better ways to do the work, the team’s informed decision on its own strategy, process, and plan will actually produce the best way for this team to do this job.
When people are discouraged, antagonized, or even just unhappy, they cannot do their best work. The key to getting superior work from creative people is to energize the entire team and to motivate all of the members to do their very best. But what motivates software people and how can one build and sustain this motivation? In an interesting study of software projects, Linberg compared management’s typical views of project success with those of the team members . While managers typically think in terms of cost, schedule, and product success, the developers viewed their projects quite differently.
For example, Linberg asked one group of experienced developers what project they viewed as the most successful one on which they had worked. They had just completed what he referred to as project A and over half of them cited this as the most successful of their careers. This was in spite of the fact that they had all worked on eight or more projects and that this job was delivered in twice the desired time and for three times the planned cost. The four factors that the team members listed as making this project successful were as follows.
These are the things that motivate software developers. While these same factors motivate people in almost all walks of life, they are particularly important for getting superior software work. In many fields, people’s personal practices are visible and relatively easy to measure and monitor. In software, much of the work is intellectual and not measurable or manageable without the developer’s cooperation. This is why motivation, personal discipline, and sound professional behavior is so important for software development. If software people do not want to work in a particular prescribed way, they won’t and, unless the software people themselves tell them, it is unlikely that anyone will know. This is why contributing, being involved, being rewarded, getting positive feedback, and having autonomy are particularly important for software developers.
Whether you manage software development or do development work yourself, remember and follow these four principles. To produce superior products, the developers must
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Dan Burton, Anita Carleton, Julia Mullaney, Bill Peterson, and Marsha Pomeroy-Huff.
In these columns, I discuss software issues and the impact of quality and process on developers and their organizations. However, I am most interested in addressing the issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
 Davis, N. & Mullaney, J. The Team Software Process (TSP) in Practice: A Summary of Recent Results (CMU/SEI-2003-TR-014). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
 Linberg, K. “Software Developer Perceptions about Software Project Failure: A Case Study.” Journal of Systems and Software 49, 2 (December 1999): 177-192.
* TSP team projects start with a launch where the members learn the project requirements, define their own processes, and develop and negotiate their plans with management.
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.