I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams.  It wasn’t because the material wasn’t good — it definitely is.  It’s not because I felt squeamish about the title — I didn’t.  However, I did feel like I should have somehow managed to have read it before now.  With the original edition written in 1987 and the 2nd edition written in 1999 — I should have read it before now.  Alas, I hadn’t.

Peopleware is, as the title suggests, about people.  It’s about how people and software development fit together.  It’s not another methodology, it’s not a set of programming tips.  It is, however, some interesting insight on how people work, don’t work, and work together.  It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.

I collected a few quotes that I believe highlight the value of the book:

• “The major problems of our work are not so much technological as sociological in nature” (p4)
• “The statistics about reading are particularly discouraging.  The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.” (p12) [Ouch]
• “People under time pressure don’t work better; they just work faster.” (p18)
• “Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code.” (p21)
• “People just don’t work effectively when they’re locked into a no-win situation” (p28)
• “The manager’s function is not to make people work, but to make it possible for people to work” (p34)
• “People can keep track of only so many human interactions” (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]

The book read, to me, as the background information one needs to understand why agile methodologies work.  It’s sort of like reading a book about the internal combustion engine when you drive a car to work every day.  You don’t have to know how the car runs, but when you break down on the side of the road it comes in really handy.

If you’ve not managed to make it through this classic work and you work with others as a manager or as a team member — you should.