Saturday, 26 November 2011

Peopleware Review

This post is a review of Peopleware: Productive Projects and Teams (Second Edition) by Tom DeMarco and Timothy Lister

Peopleware is a book that I read with great expectation. It had been mentioned in other books and online review with high reverence so I was expecting much from it and it certainly delivered. A point to get out the way early on is that the book is really aimed at managers of programmers rather than programmers themselves but I still think it is a book that every programmer should read. The usefullness for programmers comes from a couple of things, firstly, that some of the points made can be applied to your home environment and projects and secondly it contains great ammunition for negotiating workplace practices and environment with your boss in the form of reasoned arguments and evidence from studies.

The book is written in a relaxed and casual style which makes for easy reading but doesn't stop the authors from bringing out dry statistics when required to prove a point. It covers a wide range of managerial topics, from building successful teams to setting up the most productive workplace environment.

I didn't end up making too many notes on the book, because of the irrelevence of some parts of the book to me in my current role, but the book will be a very useful reference to have on hand when negotiating about the workplace with managers. Some of the points I did find interesting and relevant enough to note down were:

  • Failing projects are more often caused by sociological problems than technical ones
  • Often projects spend too much time trying to get things done and not enough time asking if they should be done
  • Most overtime tends to be followed with compensatory "undertime"
  • "People under time pressure don't work better; they just work faster"
  • People tie their self-esteem to the quality of a product, not the quantity
  • Increased quality -> increased motivation -> increased productivity
  • Parkinson's Law doesn't apply to work you enjoy ( and apparently the law was never backed up with any evidence in the first place)
  • In a 1985 study, the most productive projects had no time estimate or schedule
  • "The manager's function is not to make people work, but to make it possible for people to work"
  • Music lessons creativity as they are both right side of the brain activities (evidence in study)
  • The Hawthorne Effect: "people perform better when they're trying something new"#
  • Think of a work team as a choir not as a football team
The point about developers (and likely people in general) tying their self-esteem to the quality of a project rather than the quantity is something I'll be trying to keep in mind at work. The quality required for maximum business value is often going to be less than the level a developer would be most proud of, so I'll have to remind myself of this when a manager wants to release a product when I would consider it too early. Though I'd be very happy if my manager took interest in the follow up point that better quality leads to better motivation leading to better productivity.

In conclusion, I don't think the average programmer will find too much of immediate practical use in Peopleware but I'd still recommend that they read it for the insights it provides into the workplace environment, it's usefulness as a negotiating tool with managers and in case they ever want to step into management. As with my review of Mastering the Requirements Process, this is the first book I've read on the subject, this time management, and so I don't have much to compare it to, but as a developer I feel that if a manger were to implement the suggestions of this book then I'd be a happier and more productive developer and in some cases the book contains the statistics from trials to back up this feeling.

Link to buy the book at

1 comment:

  1. In a 1985 study, the most productive projects had no time estimate or schedule > this is very wrong.