Read an Excerpt
PREFACE: Good software does not come from CASE tools, visual programming, rapid prototyping, or object technology. Good software comes from people. So does bad software. In 1992, I started writing a regular column with this simple premise: since software is created by people and used by people, a better understanding of people - how they work, how they do their work, and how they work together - is a basis for better software development and better software. The subject of the column was not hardware, no t software, but peopleware.
In a field peppered with neologisms, peopleware is one of those few that really needed to be invented. Peter G. Newmann, perhaps best known for his regular reports on the human risks and real hazards of computers and computer programs, appears to have been the first to use the term in print, in a 1976 paper called Peopleware in Systems in an obscure book that took its title from the paper. The word seems to have been independently coined by Meilir Page-Jones, who used it in the 1980 edition of his Practical Guide to Structured Systems Design, the book that finally made my work on structured design understandable to the average programmer. But peopleware most likely became lodged in the permanent lexicon of our field with the 1987 publication of a great little book by that title from Tom DeMarco and Tim Lister. In calling my column Peopleware, I was cribbing from the best.
Peopleware is really the third frontier of the computer revolution. First came the hardware crisis. At one time we thought our problems were really due to hardware. If only we had faster and more powerful computers, we thought, with more memory and betterperipherals, then we could build better systems; we could solve our problems. Well, we got better computers. Year after year the hardware grew swifter, the memories larger, and the peripherals more versatile and ergonomic. And our problems persisted. We still delivered hard-to-use systems; we still ran late and over budget with our projects. So we concluded that the real problem was software, and the front lines in the revolution shifted to what many came to call "the software crisis." If only we had better tools, higher level languages, richer component libraries, and programs to help us build programs, then we could solve our problems and deliver good systems on time and within budget. The third-generation languages grew more sophisticated and begat 4GLs.
Compilers grew faster and more clever. Libraries of reusable components expanded, editors became context-sensitive, and computer- aided software engineering tools sprang up from every point of the compass. On the heels of the structural revolution that gave us structured design and analysis, object orientation began to mature and gained in popularity. Still, schedules kept slipping and budgets kept busting, and everywhere the bugs remained stubbornly bugs.
At last, like Pogo and his fabled friends from Okeefenokee, we were forced to recognize where the problem lay. "We have met the enemy and they is us," said the unwittingly wise little possum. Indeed. Peopleware is the real issue. We are the problem a nd we are the solution. How convenient.
Peopleware spans a pretty broad panorama. Anything that has to do with the role of people in the software and applications development process is within the purview of peopleware. The column, like this book, touches on an assortment of issues scatter ed around that landscape: quality and productivity, teamwork, group dynamics, personality and programming, project management and organizational issues, interface design and human-machine interaction, cognition, psychology, and thought processes. All of these things interest and excite me. They always have. I took my degree in management in part because it allowed me to mix computers and systems theory with psychology. My thesis was on the psychology of computer programming. I introduced psychologist George Miller and his magical number (72, of course) to thousands of students and dozens of colleagues over the years. The structure of structure charts was carefully devised to aid visual concept formation and problem solving. Coupling and cohesion, those venerable metrics at the heart of structured design, are really about computer programs as viewed by people. What makes programs complex or simple is precisely whatever is complex or simple to the minds of the programmers who write, maintain, and modify them.
In a sense, I can't stay away from the people issues any more than I can stay away from computers. I thought I had escaped when I bid farewell to the computer field in July of 1976, declaring my independence even as America celebrated the bicentennial of its independence. Trained as a family therapist, I ended up spending more than a decade in private and agency practice working with couples and families and troubled adolescents. But the forces of the universe conspired to steer me back toward the technological frontier.
Peopleware is a crossroads on that frontier, a junction where highways from my different worlds intersect. Management, organization development, personality, modeling, tools, methods, process, human- computer interaction, whatever. At one time or another I've written and worked and taught in all of these areas. The column has given me the excuse to wander again over the landscape, like a Charles Kuralt, stopping to explore interesting ideas, taking up challenges where they arose, cruising the interstates and county roads of software and applications development.
This book logs the journey so far, starting out in Computer Language Magazine and continuing in the retitled Software Development. The column is still just called Peopleware. Here are the first thirty- something columns and a few closely related side trips published in other places. The essays and articles have been edited for continuity, and some material that was deleted when they were cut to length for magazine publication, has been restored. This, then, is the director's cut, arranged into quasi-logical sections that contribute to a certain illusion of organization. But this is no encyclopedia or textbook, not even a road map of the vast territory of peopleware, just the journal of one pilgrim. The pilgrimage continues.