The Peopleware Papers
This book is about the other side of computer software, the side facing outward. This face of computing touches and is touched by people-technology people, like you and me, and ordinary people, like you and me. The essays here compiled explore the many diverse aspects of peopleware-that interface between software and its developers and between software and its users.
Review By: Bob Pardee
05/03/2002Constantine looks at software from a different perspective than we’re used to seeing. Rather than focusing on software and systems, he writes about people. While some of the book will speak to developers, it speaks most directly to team leads and management in software development organizations. Included are tips on team organization, interaction with other groups, and other human aspects of software development.
The author investigates human issues surrounding software development. He begins with the topic of group development (a recurring theme throughout the book). Most books dealing with group development put the emphasis on “development,” but this one puts the emphasis on “group”: how a group gets things done to make software, rather than how one makes software…as part of a group.
The book begins with a discussion of team roles and team decision-making processes. Constantine has a social science background, and he provides references to the original source material for those who want to read more about the origins of many of the ideas presented in the book. But the book is not a social science text; it has been written to appeal to the development community, rather than to researchers.
The next section focuses on the individual in a team, and in particular, on programmer personalities. The author discusses Coding Cowboys, and the tendency of many programmers to work individually and then try to pull things together (or let someone else do so) at the end of the project. He discusses some strategies for working with Coding Cowboys and Cowgirls.
Other topics discussed in the book include team organization (with a comparison of management styles), development tools (paying particular attention to how developers use these tools, or don’t), and software usability (including discussion of the tradeoffs between a simple, easy-to-use product, and a product with lots of features).
The book is a pleasant read. The author keeps you reading with humor and stories, and provides value by making strong arguments for the viewpoints he presents, backed up by psychological and sociological research. The result is a more lighthearted look at team organization than other software management texts.
The book is a collection of essays by the author, which originally appeared in his magazine columns. This is both a strength and a weakness of the book. It is a strength, in that the style is casual, and individual sections of interest can be read separately from the rest of the text. It is a weakness, however, in that the chapters are not as tightly integrated as one might expect in a book. The author sometimes repeats himself (whole sections of text), probably for magazine readers who missed a previous issue. Still, if you can forgive this minor failing, the writing measures up very well in every other respect.
In general, I found myself agreeing with the author’s major points. Some of what he says seems like common sense, but so often we ignore what is common sense. Other points were less obvious, until they had been adequately illuminated through the use of anecdotes drawn from the author’s own experiences in the consulting industry.
While I doubt that this book will become a “classic,” I recommend it to software team managers. Developers would enjoy (and hopefully take some lessons from) the sections on tools and usability. The book is written in such an engaging style that most will probably want to read all of it.