Last week I was sick. So I curled up on the couch and read Peopleware: Productive Projects and Teams, 2nd Ed. by Tom DeMarco and Timothy Lister. Larry Price’s fantastic review the week before moved it from unknown to the top of my reading list.

It helped while away the uncomfortable hours. And not just while the hours away: it made them fly. I thoroughly enjoyed this book. I kept turning pages until I had finished the entire volume in a single sitting.

If my enthusiasm for this book grabs your interest, head over to Larry’s review for substantive reasons why you should read it. Then continue here for my own scattered thoughts.

What’s the point?

This book doesn’t have a singular point as much as a unifying theme. It centers on successful software development by fostering productive teams in good environments. It touches on managing teams, creating producing team environments, quality developers, jelling a team, and having fun. All these subjects are explored with a healthy bit of storytelling and personal experience. Many of the things they write “rung true in my heart.” These were things which I, for whatever reason, already believed, but had never deeply thought about.

How was it?

This book was enjoyable. It was first written in 1987, and when they came out with the second edition, they didn’t change the good old stuff. They just added new chapters so the old chapters still have an old feel. It would make the book seem dated if the content wasn’t still so relevant today.

Here are some essays (chapters) I particularly liked and got me thinking.

Thinking On The Job

One afternoon… Wendl was staring into space, his feet propped up on the desk. Our boss came in and asked, “Wendl! What are you doing?” Wendl said, “I’m thinking.” And the boss said, “Can’t you do that at home?” ~p.67

I feel that I don’t take enough time to think at work before acting. Acting seems productive, but sometimes a little thought beforehand can provide a better answer than just running with the first thing that pops into my head. I need to learn how to take the productivity ‘hit,’ put my head down on my desk, and just concentrate for a bit. I think I’d be better in the long run.

Happy To Be Here: The Mentality of Permanence

In this chapter they talk about how productivity gets lots of air time but employee turnover gets very little. They point out that trying to ring the most out of every hour of work (or, in pointy hair boss situations, the most out of every hour of pay) can take its toll on the employee and cause them to leave the company.

I’m in no danger of that here at SEP, which is wonderful. In fact, we have a very strong culture of permanence. I see SEP in this quote:

The best organizations are consciously striving to be the best. This is a common goal that provides common direction, joint satisfaction, and a strong binding effect. There is a mentality of permanence about such places, the sense that you’d be dumb to look for work elsewhere—people would look at you as though you were daft. ~p.111

I always though the talk of “we’re the best” was just shallow self-congratulations, but I’m beginning to see it as important cultural reinforcement. We’re constantly telling ourselves that “best” is who we are, not in a Rest Upon Our Laurels kind of way, but as an acknowledgement of the importance of excellence. It’s a cause that we are reminding ourselves to reach for in each little working moment. “We Do Quality Work. Trademark.”

On Not Breaking Up the Yankees

A team that has jelled together and is functioning well can get a lot of things done well. Much of this book was on the power of teams, how to get a team to jell, and (mostly) all the easy ways to mess it up and ‘kill’ a team’s ability. So teams are fragile, but powerful once formed. It is in the interest of the company to hang on to that achievement.

If a team does knit, don’t break it up. At least give people the option to undertake another project together. When teams stay together from one project to the next, they start out each new endeavor with tremendous momentum. ~p.155

Somehow SEP has managed to be successful with an almost complete lack of continuity in teams, as far as I can tell. Our mix-and-regroup method is working great, but I wonder if experimenting with continuity might lead to an even better system. It would be good to try.

Who should read this book?

All software developers and managers should read this book. For a book that’s almost 30 years old, it hits very close to home. If 30-year-old answers (or at least warnings) are available to problems we still face, it probably behooves us to pay attention. It’s silly to repeat the same mistakes time and again. I purpose to be a Holgar Dansk (p.173) and work for organizational improvement, and I love it when I see other people in software doing the same.