“Keeping you up to date with everything software engineering!”

Peopleware: Managing Projects and Teams

Book Reviews | October 19, 2004 | 15 comments

Another day begins, - you go to work, enter your cramped cubicle, turn on your desktop, and prepare for another busy day at the office.

Soon after you start working, a customer using your latest application calls in - frantic because your product keeps crashing. You spend twenty minutes troubleshooting the crash, resolve the issue, and resume your work. A coworker comes to see you about a problem with your latest build of the software you’re working in. Soon after, you’re called into a status meeting and listen patiently as the manager calls in the status from every one on your team. Another manager seeks you soon afterwards, needing someone to demo another application for a visiting client. Pretty soon, half the day has gone by and you feel like hardly any work has been done.

If this situation sounds awfully familiar, it’s for a good reason. We’ve all faced this situation at one point of our professional lives. Managing disruptions in your workflow is just one of the topics covered by Tom De Marco and Timothy Lister in “Peopleware: Productive Projects and Teams, 2nd ed.”.

The book focuses solely on the important social aspects of managing and working in a software development environment - an aspect surprising (or unsurprisingly) ignored by managers. De Marco and Lister have found, through their years of consulting with companies and analyzing the projects that failed, that, without exception, the causes of project failures were never technical in nature. Many projects were aborted due to what employees like to call “company politics”.

Of course, when a project fails, the first reasons that come to mind are that the requirements were too vague and undefined, the deadline too tight, a new technology was too great a risk… but how often is the impact of adding a new employee on the project considered? Could it be possible that the environment is just too noisy to be productive? Are employees being discouraged from trying new design ideas because of a rigid methodology /process imposed by the corporation? Does management approach software development the same way they would manage an assembly line, standardizing procedures and viewing employees as interchangeable?

Topics that “Peopleware: Productive Projects and Teams” cover include the makings of a successful teams, the obvious and hidden costs of turnover, and creating a work community which makes employees enjoy their work and want to stay.

What sets the book apart from others I’ve looked at, is that its hard to put it down - partly due to the abundance of real-life examples, some so incredible it makes you glad you’re working in a different company. If you’re a developer yourself though, its hard not to identify with a lot of the points the authors are making - you’ve likely experienced them in your own workplace. And that’s what makes their arguments very easy to believe and accept - its all common sense and its stuff you knew all along anyway!

Its too bad however, that solving the problems you’re now suddenly aware of seem like a Herculean task. Just try convincing management to provide taller dividers, more office space, and quieter environments. But at the very least, learning about the social aspects of software management can at least provide a catalyst to start discussions. It may be difficult to bring about change, but all it takes is one determined individual.

“Peopleware: Managing Projects and Teams” is not just for managers - It would be great if everyone in my department could read it. Personally, I have not looked at work the same way since.

I think if there is one theme the book is trying to impart on its readers, it’s that the most valuable resource in any organization is its people, and it’s very few organizations that realize this. But everyone wants to work for the ones that do.

I know a lot of you have already read the book. What did you think about it? Did it have the same impact on you? What was the nuggest of valuable information you remember the most from the book?

Related Links:

• Book: “Peopleware: Managing Projects and Teams” (Amazon: Canada, US)
• Reviews on publishers website
• More Info: Tom DeMarco
• More Info: Tim Lister

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 20, 2004 09:52 PM | ElvisIsGod commented:

In my experience, most programmers are thinking about themselves and where they can get a better salary, doing the least amount of work, working on pet projects, wanting the latest toys, lunch, vacation, the last sci-fi movie (amongst other things). - Loyalty is not something that I have found to be ingrained. Does the book address changing the mentality of programmers?

I should note that I have been very lucky with the teams that I directed. Part of this, I think is that you have to consider individual needs. Showing a real appreciation for work done, being open to suggestions, giving freedom to try new ways. Small gestures such as giving part of an afternoon off, sending flower to their loved one if they worked late, taking the time to listen to their concerns, free lunches do help with loyalty. Part of the problem with managers is and “us and them” mentality. Many, if not most, problems come from the head of companies - their attitudes are reflected throught the rank and file.

October 20, 2004 10:17 PM | John Kopanas commented:

I think it has become a chicken and egg problem. Now who is going to change first? :-) I personally think businesses need to change first since they have the most to gain and loose.

October 20, 2004 10:29 PM | ElvisIsGod commented:

If a company does not do well, you don’t do well as a programmer. If has to be a little of give an take.

A business can always find a code monkey to do the work in the end…

October 20, 2004 11:01 PM | John Kopanas commented:

With the rate of project and company failure thinking of the people responsible for your companies success or failure as a coding monkies I guarantee you that you will increase your chances of failure greatly and loose much more time and money then if you would of managed your people properly in the first place. :-)

October 21, 2004 07:53 AM | David Di Giacomo commented:

Peopleware does discuss the prevailing attitude that “coworkers are just thinking about themselves and what they can get.”

Experience has shown the authors however, and I would tend to agree, that workers do have an intrinsic desire to do a good job, provided the work is satisfying and presents them with some challenge.

They don’t do so for the company, they do it for themselves, because they take pride in what they do. This kind of attutude isn’t resevered for the one or two exceptional performers, as management tends to sometimes think, but inherant in many. Give workers no challenge, bad environments, and make them feel like code monkeys - make them feel like an expendable part - and you’ll never see what I’m talking about.

October 21, 2004 02:30 PM | John Kopanas commented:

I agree with David, even if employees are not as loyal as they used to be you still want to get the most out of them. My opinion has always been that a manager is like a coach in the respect that it is their job to get the most out of their players… no matter how long they will play for you.

October 21, 2004 02:31 PM | ElvisIsGod commented:

John, not all programmers are created equal - being saddled with someone who is unproductive will never help a project. It should not be a “chicken and egg” situation. That is the wrong attitude to have going into any scenario. Often the admin of a company does have to deal with the client, the programmers, the managers - all with their own agendas. As the the head of a company, if I get too much resistance or lack of cooperation from programmers towards a common goal, then yes, they become in my mind code monkeys. A prima donna vision will encourage outsourcing - we have a job to get done. It goes beyond “managing people”- How many programmers really read SRS’s, data diagrams? How many really try to get a global vision of the application before blindly typing code? Using the best practices of managing people only goes so far…

October 21, 2004 02:42 PM | ElvisIsGod commented:

David, thank you for the follow up. All workers should have an intrinsic desire to do a good job - yes but often they get distracted - managers have imposed restrictions to reduce distractions and in the process have imposed poor work conditions… Finding that balance is something that should be strived for. Finding the right amount of challenge so that a employee feels satisfied all the while helping a firms bottom line is something that is hard to master. You will always have exceptional performers, they are often the ones that help weaker members of a team - and helping overall morale. Yes management can be thick - a company I worked for would hire any project management - even if they had no understanding of programming.

October 21, 2004 05:21 PM | John Kopanas commented:

For those following this conversation. Elvis used to be my boss for many many years. I started programming for him even before I was in software engineering at university. I think Elvis and I were together for approx. 6 years.

I know Elvis that you have had bad luck with programmers… in some cases that included your experience with me :-). In general though, the majority of my friends are very competent engineers and take the time to read and understand the project they are working on.

I strongly believe that the most important department of a company is the HR department. Unfortunately most interviewers just look for keywords and don’t know if the person knows what they are talking about or not.

It is 6:15 PM and I am still at work and so are the majority of my co-workers. These people really care about what they do. All day I hear them yelling back and forth about this use case and that use case. They read the SRS documents a little too much :-).

October 22, 2004 10:02 AM | ElvisIsGod commented:

John, I never considered you an employee, still don’t. When I speak about my experiences with programmers it is based on a few other companies I have been involved with.

John, hearing people yelling back and forth is not conductive to good programming, no?

October 22, 2004 01:04 PM | John Kopanas commented:

No… not at all. What are you refering to though :-) ?

October 22, 2004 01:31 PM | ElvisIsGod commented:

October 22, 2004 01:04 PM | John Kopanas commented: No… not at all. What are you refering to though :-) ?

October 21, 2004 05:21 PM | John Kopanas commented: These people really care about what they do. All day I hear them yelling back and forth about this use case and that use case.

October 22, 2004 08:57 PM | Gili commented:

Here is my point of view, for what it’s worth. It has been my experience that it is extremely hard to find smart, motivated and focused programmers these days. Every single one of these components are important. For example, I’ve seen smart people get hired, then after many years of being mistreated by management they turn into disgruntled employees and it becomes very difficult to turn them back. I’m not even sure that you can ever turn them back.

Another issue no one seems to discuss is focus.

I see a lot of good people who are just too damn socialable. They spend the majority of their day walking around and talking with people, often discussing things like design pattern theory. Yes, design patterns are nice and all but when you spend 75% of your day wasting your time and other people’s time and only 25% of the time actually doing any work, you don’t get anything done.

PeopleWare identifies people that act as the “glue” of software teams, holding them together, helping training people in the group etc. It is my opinion that these specific people I am refering are not the same ones being discussed by PeopleWare; but they are similar. I’m not talking about people who just need to take a break between work every now and then (we all need that). I am talking about the people who love talking for the sake of hearing their own voice.

I have some people in my office who do nothing all day except send out useless emails about company health policy, stock options, etc when their actual job has nothing to do with that. They’re not HR for godssake! :) I see them spend hours putting together tax excel sheets and sending it out to everyone else because god forbid people should do their taxes without using their special excel sheet which is so damn helpful. Again, this is all very nice and socialable, but I’d still fire their ass the second I see them. A company is a not a party room. People who distract others and can’t keep the eye on the ball are a hazard.

So in summary: there are the follow bad groups of people I would fire :)

1) The poorly skilled labour. Can’t code well and drag everyone down with them.

2) The lazy skilled labour. They browse the internet all day long and play mindless online games as soon as your back is turned.

3) Pointless socializers that go around doing things that help no one and create noise.

4) People who speak too loudly, for long periods of time, whether or not they are on the phone … and have no office with a closable door.

It’s like a whole new dilbert world :) What has your experience been in this domain?

Gili

October 23, 2004 12:26 AM | ElvisIsGod commented:

Gili, noting to add, you have echoed my thinking…

November 3, 2004 08:41 AM | John Kopanas commented:

I guess I would be fired for number 4… maybe even number 3. But I never thought it was pointless.

I received my copy of Peopleware yesterday and I have not put it down. More authors should write very short and to the point chapters like the authors of Peopleware did. I find the style more rewarding as a reader because I feel like I am accomplishing more even though I am reading the same amount of pages. Just a preference.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)