Peopleware Review
Tags: bookreview, post
Published: 2019-04-21 14:06:38

---
title: Peopleware Review
published: true
tags: book_review,post
canonical_url: https://horia141.com/peopleware-review.html
series: "Book Reviews"
---

Managed to finish [Peopleware](https://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439) this last week. It’s a classic of software development, so it barely needs an introduction or review from me. But since it’s been a while since the last non-”Friday Blast” article, here we go.

The main idea of the book is that the big problems we face in software engineering are people problems rather than technical ones. Given companies and teams where people are respected and where they can work _well_, technical issues can always be surmounted. The book focuses on small teams - so it’s mainly going to be useful to individual contributors, team leads and line managers.

I think my biggest takeaway is how much I agreed with it and how much of the material seemed “well duh” obvious. Which speaks to its influence as well as other more systemic changes in the way companies treat knowledge workers and software engineers in particular. But perhaps it’s also a bias from the kind of companies I’ve worked at. Please chime-in with counter-examples.

The book is divided into six parts, each covering some pathology of the workplace or a way to improve it and build good teams.

The first part deals with managing humans per-se. Some interesting things of note here are a rebuke of [Parkinson’s law](https://en.wikipedia.org/wiki/Parkinson%27s_law) - that work expands to fill the time allotted to it, and managers shouldn’t impose harsh and unrealistic deadlines because of that; a rebuke of “quality doesn’t matter” principles - which makes folks not care about the product and their work and team in general, and that just letting folks work to their desired standard of quality will produce software on time etc. One interesting anec-study they compiled was about setting schedules for work. The fastest way to build software seems to be to let the team itself set the goals and deadlines they want to achieve - this has been consistent with my personal experience. And indeed, in some of the best teams and projects I’ve been part of there was _no deadline from above_.

The second part is an attack on “the modern office environment” ca late 80s. Nothing mind-blowing here - open plan offices suck for creative and [deep work](https://dev.to/horia141/deep-work-review-5591). Things have gotten worse though in the meantime, and even companies known for how well they treat their employees - such as Google and Facebook - use open plan offices a lot. OTOH, there’s only so much you can do if you want an office in central London under 10 billion.

Part three deals with hiring the right people and keeping them on board. Hiring for fit to the team is the biggest take-away I got from here, but also hiring from various backgrounds. It seems many folks focus on the first thing, using “culture fit” as a tool of discrimination. But they’re very adamant that that’s a bad thing in general. Ahead of the curve on that one, but the second part is beginning to be more grounded lately, with _diversity_ even being considered [a competitive advantage](https://techcrunch.com/2016/09/16/the-competitive-advantage-of-diversity/).

The fourth part deals with building teams that _gell_. Those sorts of teams which work well together, have high output, low-turnover etc. This section contains _some_ advice for trying to build such teams as a manager, but does acknowledge that it’s a hard task. And even one with a low level of repeatability.

Finally parts five and six deal with setting up a good environment for folks to work in. Both at the physical level, but also at the organization level.

There’s some bad parts to the book. And they’re all basically linked to the fact that the book has a certain age. It was written in 1987, and presumably built on knowledge gained in the 70s and 80s. So for the modern reader some aspects will seem unfamiliar. Unfortunately the 2013 second edition didn’t manage to address them.

The biggest thing is that there’s almost no focus on _tech startups_ as we’ve know to understand them from the 90s onwards. There’s instead a focus on big corporate settings, with huge projects, years long sprints, _cost cutting measures_ and waterfall approaches to software development. And even in the massively dominated by outsourcing Romanian IT industry it’s not the case anymore that things are done like that. Which might be a plus-point for the book however - it’s message was received and things have changed.

There’s no mention of the massive shortages of qualified people which have created a strong seller’s market and tilted the balance in favour of workers in many places, thus forcing out some of the bad practices of the past. Companies actually _do try_ to create good work environments for their people (at least at a larger scale than previously seen).

There’s a japanophile vibe through some chapters. Again, it was the 80s and it shows. But some things haven’t aged well - the phrase “open kimono” seemed a bit off when I first encountered it in the book. Upon a bit of research turns out it’s a true clusterfuck of a saying, managing to be both racist and sexist at the same time. Nice.

Despite the shortcomings from above, this remains a classic and for good reasons. Check it out and convince yourself.