Peopleware; Productive Projects and Teams
Tom DeMarco & Timothy Lister

Note: This review is of a software development book, not a work of fiction. The book that is; the book's not a work of fiction. Neither is the review, I hope.

I’ve heard about this book very often from Joel, of JoelOnSoftware.com. He recommends it very highly, in fact one of his recommendations is on the back. This is also one of the first ‘software development process’ books that I’ve ever managed to read cover-to-cover, all the way through, and in only a day and a half. Usually these sorts of books are very dry, kind of suck and end up just annoying me.

This book is different, however.

Essentially, Peopleware is saying that any attempt to project manage software development is doomed to (painful) failure if it focuses on issues like technology or process and policy. The point is that like most things humans do, the problems are usually sociological. It’s all a matter of getting different people to work together — understanding how they think and what is important to them at a very personal level is how you achieve this.

Joel makes a big deal of how important the office environment, particularly a quiet space with a door that shuts, is to any software developer. This book really makes that very clear. All ‘knowledge’ workers need some level of quiet and privacy, or there really is no point in having them around. The book took the discussion further and points the reader off towards Christopher Alexander, as the entire environment from the building down to the angle of the desk matters.

As an aside, if you haven’t heard of Christopher Alexander, then go read about him. He has nothing to do with software development. He’s a real architect. Not one of those pretentious software ones. Anyone who ever lives or works in a building should have some idea of what Alexander is on about.

I can’t overstate this, if you currently manage software development; would like to some day manage software development; or are a software developer being managed, you really should read this book.

And the thing is, if you aren’t in software development but can ignore the references while reading this book, you’ll find it useful. The principles apply to any job where the workers are required to think independently to get anything useful done. If you think while working, this book is for you.