HackerTube.live
Books / Business

THE READING ROOM / BOOK GUIDE

Peopleware

Tom DeMarco; Timothy Lister

Two software veterans argue that failed projects often trace back to how teams are housed, interrupted, and managed. The book makes that case through observation and anecdote.

About the book

Peopleware examines why software projects fail for reasons that have little to do with code. Tom DeMarco and Timothy Lister, both longtime figures in software management, turn their attention to the workplace itself: the office, the team, the schedule, and the habits of the people who run projects. Their central claim is that managers treat people like interchangeable parts and then wonder why the results disappoint.

The book works through themes such as the cost of interruption, the value of private workspace, the psychology of team formation, and the ways organizations reward the wrong behavior. It draws on surveys and field observation of programmers and their workplaces, and it uses those findings to question common management practices. The writing is direct and often wry, built from short sections and concrete examples.

The book reflects the software industry of its moment, but its concerns about concentration, office layout, and managerial attention have stayed recognizable to later readers. It sits in a tradition of writing about knowledge work that treats working conditions as a management problem.

How to read it

Read it as a set of arguments to test against your own workplace. Each section makes a claim about how teams behave, then supports it with observation or survey data. Pause on the claims that seem obvious; those are often the ones the book is pushing against.

The prose is short and accessible, so the book moves quickly. The difficulty lies in the age of the examples and the occasional generalization. Note where the authors reason from a specific study to a broad rule, and ask whether the rule holds in your setting. The sections on office space and interruption are the most concrete and the easiest to apply.

Who it suits

Managers of technical teams, team leads, and anyone who has watched a capable group struggle inside a badly organized workplace will find useful language here. Software developers who want to understand why their environment works against them will recognize the complaints. Readers interested in the history of management thinking about knowledge work will also get a clear picture of the arguments that shaped later practice.

Reading considerations

The book's examples, office norms, and survey context belong to the 1980s; later editions update some material, so check which edition you have. Some claims rest on observation and survey data rather than controlled study, and the authors sometimes generalize from a particular workplace to all of them. Treat the recommendations as arguments to weigh against your own conditions, not as settled findings.

Follow the HN conversation

276 different recommenders are recorded in the upstream dataset. These are AI-classified source counts, not an independent rating.

Search HN comments about this book ↗

Explore videos on the same subject ↗

Book notes prepared with DeepSeek, using catalogue records and Open Library subject information. They are reading guidance, not a personal review or a verified chapter-by-chapter account. Book details can vary by edition. HN data methodology · Book metadata and covers.