The book Peopleware by Tom DeMarco and Timothy Lister is a popular book on software project management. The first edition was from 1987 but the book has been revised in 2013. Peopleware addresses the issue of software developers management.

This article is a short-list of what I take away from the book. The book is really easy to read and full of interesting insights, I recommend it to anyone working in software projects — even if you’re not into management.

The authors note that a lot of software projects fail, and that in their experience, most of the time the failure is “people-related”. The main thesis is stated in the first chapter and reads:

The major problems of our work are not so much technological as sociological in nature.

The book is divided into 5 parts, but I think we can extract 2 main ideas:

1. Productivity in a software project is quite different than in a physical product assembly line (eg Cheeseburger production),
2. You will have better productivity by actually showing respect for and trust in your people.

The authors explain the first point to support the second, and then expand on the multiple facets of what makes software developers work better.

Productivity reassessed

Software development is a work of the mind. It requires abstract thinking and creativity. On the opposite, making a Cheeseburger requires no novelty, and production can be standardized.

When you replace a developer, you find a person with a different experience each time. Turnover is more costly than you think. On the contrary, a Cheeseburger maker is quite interchangeable.

When developing software, quality matters a lot, because software is evolving and must be maintained. You can’t trade-off quality for productivity.

What’s not so easy is keeping in mind an inconvenient truth like this one:

People under time pressure don’t work better — they just work faster.

In order to work faster, they may have to sacrifice the quality of the product and of their own work experience.

How to care for software developers

If you want to know all about it, go read the book. Here I will keep 5 points that I found particularly interesting, considering my short experience of software development.

Respect their work

• Allow, even encourage errors: they will feel more free to try new things and will learn in the process.
• People’s self-esteem is tied to the quality of the work they produce: strive for quality.
• Be open to change.
• Create an atmosphere of safety, remove competition inside a team.
• Avoid unnecessary dress codes, Methodologies, and bureaucracy, which make people feel that their appearance, or a Method (with a big M), or the politically-correct, is more important than their actual work.

Chris Lema selected that last point as one of the Three Reasons Why High Performers Quit:

Proper procedure is more valuable than high performance.

Respect their time

• Sometimes a developer has to stop coding and think. That’s OK.
• Avoid useless meetings, etc.
• Avoid impossible deadlines: your developers also want the work done, they’ll do it even without a deadline.
• Be aware that working more is not being more productive. Respect your people’s work/personal life balance.

Your people are very aware of the one short life that each person is allotted. And they know too well that there has got to be something more important than the silly job they’re working on.

Let them work in peace

The main idea is that building software involves building abstract ideas. The developer is then in a fragile state of flow.

• Give them a nice, quiet place to think.
• Don’t let them be interrupted in their work at any time (including with your own visits). Be mindful of the effect of meetings, telephone, emails, etc.

The authors actually devote a full part of the book to the workspace. This is reinforced by Joel Spolsky, for instance in 2000 with Where do These People Get Their (Unoriginal) Ideas? and in 2006 with A Field Guide to Developers.

Help them make progress

• Trust people: let them be autonomous after you’ve entrusted them with your job.
• Use deadlines so they see the work progresses in the right direction.
• Grow teams: when people inside the team feel safe, with no competition, they’ll naturally coach each other and share knowledge.
• Facilitate learning.

Reward

• Make people feel involved.
• Make them see the work progressing with small part goals.
• Use tests for private self-assessment.
• Avoid creating competition through bonuses tied to performance.

Conclusion

The authors tell some stories and give supporting data to make their point. I think they might go a bit too far at times, for instance when they insist on making the workplace a community: some people may like it, but some may not. In any case, I believe I would work better in the environment they detail along the pages.

If you’re still not convinced whether you should read the book, there’s a more classic review here, and thousands of reviews on goodreads.

Please share your comments or relevant articles on Reddit. I’d like to write a follow-up article with some practical examples, eg a company/project failure or success due to a specific sociological factor.

Tweet