Review: Peopleware

The book, Peopleware by Tom DeMarco and Timothy Lister, comes highly recommended by Joel Spolsky and Jeff Atwood over at the Stack Overflow Podcast.  It is probably most famous for its repudiation of the idea that cubicles make a better work environment for programmers than offices.  There is a lot more to this book than just an attack on cube farms, though.  The book dates from another era of the technology industry.  It was first written in1987 with an update in 1999.  Most of the content ages very well though.  It carries a lot of sage advice that managers today would be smart to read.  Alas, the book appears to be out of print at present.  Check your local library.  That’s where I got mine from.

The book begins with a discussion of people and shipping quality software.  Among the insights are that you can’t squeeze more than a certain amount of work out of people.  If one demands a lot of overtime, people will slow down, do more of their own things on your time, and otherwise use up the time that was supposed to be gained.  The authors make the argument that quality, if allowed to be driven by the team, will be higher than if driven from above.  Peoples’ innate sense of quality is probably higher than the user demands.  Based on these statements, the authors refute the notion that the only way to get work done is to set tight deadlines.  The idea that work grows to fill an allocated space is—they say—false.  I’m not sure I fully agree.  Work does expand to fit the allocated space.  The solution is not, however, to set insane deadlines to squeeze out the work.  Instead, the solution is to set a rational deadline and keep track of progress via frequent checkpoints (ala scrum).

My favorite section is that one which talks about people.  The authors assert that great people are born, not grown.  That’s not quite true.  They are born with innate talents and then grown to greatness.  The key point though is that those born without the right abilities will never be great.  You can’t teach everyone to be a great programmer.  Sorry.  Because of this, and the difficulty in getting rid of someone once hired, it is important to set a high hiring bar.  It is better to hire and then retain the right people than to hire the average person and try to grow them into above average performers.  It’s also important to retain stars.  Invest in them. 

Beyond individuals, teams are important.  The authors spend some time talking about what makes great teams work.  Unfortunately, they don’t give a formula for creating one.  No one seems to know how to do this.  Maybe some day we’ll figure it out, but for now the consensus seems to be that they just happen.  Managers may not be able to create a well jelled team, but they can certainly prevent one from happening.  The authors calls this “teamicide” and give several examples of behavior that causes it:

• Defensive management – Managers must trust their teams.  Attempts to succeed despite their failure only poisons the environment.
• Bureaucracy – Paperwork and policies that are arbitrary and disrupt the work flow.  If management is more interested in paperwork than results, the team notices.
• Physical separation – People interact better when they sit near each other.
• Fragmentation of time – Give people only one top priority at a time. 
• Quality-reduced Product – Management cannot demand a shoddy product or the team will stop performing.
• Phony deadlines – Deadlines should be real (and realistic).  Fake ones to force out more work just cause people to check out.
• Clique control – Let people group up.  It’s called a team.

There’s a lot more in this book.  If you can find a copy, get it and read it.  There’s a lot here for every technology manager.