Peopleware by Tom DeMarco and Tim Lister - Twenty Years On
This year sees the twentieth anniversary of the first edition of Peopleware, deservedly one of the most popular books to consider the human side of software development. The book examines the non-technical factors that contribute to productive projects and teams, covering such areas as workspace layout, inflexible methodologies and inter-team dynamics.
The second edition followed ten years later, with extra chapters added rather than a wholesale revision of the original material.
The authors compare software developers to craftspeople who use their expert knowledge to construct software rather than fashioning stone or metal. Like their historic counterparts, these modern craftspeople need the correct work environment, the correct methods, and correct organisational structures.
Correct Work Environment
The authors collected a number of statistics showing the types of workspaces that led to the greatest productivity were those that allowed each worker to have their space - not just a small cubicle - but a proper office with closing door. In addition, their idea of minimising interruptions, such as electronic announcements, telephone and email, to ensure that workers kept concentration is something that modern management gurus constantly recommend.
The authors found (years before Slater) that the larger the organisation, the more likely it was to suffer from corporate entropy, where large, inflexible methods were forced onto employees for mistaken reasons. One example I experienced in the early-nineties was an un-heralded corporate announcement that stated "we're going to become a TQM company". The resultant imposed bureaucratic process slowed production and introduced inflexible working practices to such an extent that the company was taken-over a few years later. This accords with the anecdotal observation that unempowered people create bureaucracy to feel good about their work.
Correct Organisational Structures
The authors found the most productive teams were those that were self-organising and if possible, self-selecting. They exhibited a certain cockiness, believing themselves to be an elite and somewhat aloof from their perception of average teams around them. Most importantly, these productive teams had managerial freedom to behave in this way.
Almost as an aside, the authors mention techniques that anticipate modern mainstream software development techniques: firstly, the use of iterative design - one of the central tenets of agile ll development - and secondly the use of programming in pairs, which is one of the key practises in XP. This second practice was used in the authors' controlled programming experiments that produced the statistics that supported their productivity findings. The authors regarded software development as a knowledge-sharing, problem-solving exercise, where two heads are better than one; a process that was a natural lead-on from one-on-one informal coaching and advice.
The original chapters of this highly-readable book stand the test of time better than those of the second edition. The newer chapters, while still worthwhile, have the distraction of having rather out-dated technology references.
Looking across the modern offices that I consult in, it seems deMarco and Lister's findings have only partially been implemented. Extraneous distractions such as loudspeaker announcements are now largely absent but large-scale, open-plan working still seems the norm.
I wonder if there is a counter-force present; perhaps this is understandable if there are small teams where keeping half-an-ear open on the next cubicle's discussion is beneficial; but still I see open-plan offices with hundreds of people working on highly dissimilar projects. Perhaps it's something psychological: senior management liking to see swathes of people working; or simply that it seems cheaper to work that way. DeMarco and Lister would beg to differ.