Tag: demarco

Book Review – Peopleware

Title: Peopleware: Productive Projects and Teams

Authors: Tom DeMarco, Timothy Lister

Rating: 5/5

I picked this as the first book to review on my endless quest for two simple reasons:

  • It is one of my all time favourite books – a true timeless classic that really should be mandatory reading for every knowledge worker.
  • I have both the first and second editions on my reading list, so I can do a two-fer and review them both at once.

I bought the first edition in a 2nd-hand bookstore for $15 – the price is still on the inside cover. Two days later, I ordered the second edition for the eight all-new chapters.

Overall, the book holds its age well – it’s nearly 25 years old now, as it was first published in 1987. If they release a ’25th anniversary’ edition, do pick it up.

The book is broken into six sections – the last of which is for the second edition only. The sections are:

  • Managing The Human Resource – several chapters on people management skills
  • The Office Environment– all about building productive and distraction free environments
  • The Right People – covers how important it is to get the right people for your environment, not necessarily the most skilled or the cheapest.
  • Growing Productive Teams – pretty obvious; this is about how you nurture teams, how you can help make them gel, and how you prevent them falling apart.
  • It’s Supposed To Be Fun To Work Here – enjoyment and satisfaction in the work environment – what a novel idea!
  • Son of Peopleware – a reflection on the 12 years between the two editions, lessons learnt and new insights.

It’s a little dated in some ways. Some of the specific problems described in the book have gone away or reduced, while some of the specific solutions aren’t quite right anymore. But as a whole, the book is still highly relevant.

Each section is broken into several chapters. In the first part of the book, each chapter focuses on a particular issue. That may be a common negative phenomenon or anti-pattern – Chapter 3 is about overtime and workaholics, while Chapter 7 is about issues with ‘The Furniture Police’ – the people who don’t let you re-arrange workspaces to enable greater collaboration. Or it may be a positive workplace practise, such as Chapter 21 ‘A Spaghetti Dinner’, which describes a simple team-building exercise and why it works. Each chapter is short and focused – any chapter can be read in just a few minutes, which makes this a great book to read in spurts.

Here’s an example from one of the early chapters – Chapter 4 “Quality – If Time Permits”:

The Flight from Excellence

Managers jeopardise product quality by setting unreachable deadlines. They don’t think about their action in such terms; they tink rather that what they’re doing is throwing down an interesting challenge to their works, something to help them strive for excellence.

Experienced (jaded) workers know otherwise. They know that under the gun, their efforts will be overconstrained. There will be no freedom to trade off resources to make on-time delivery possible. They won’t have the option of more people or reduced function. The only thing to give on will be quality. Workers kept under extreme time pressue will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted of onto the product’s end user. They will deliver products that are unstable but not really complete. They will hate what they’re doing, but what other choice do they have?”

The chapter goes on to talk about how people don’t explicitly value quality – that given the choice between getting a barely working product on time and on budget, or getting the stable complete version a few weeks later for a correspondingly greater price, they tend to pick the former. And if it’s going to be on time and high quality, they’d rather have it earlier and buggier. While this culture is endemic – and any real world project will face pressures on both time and budget – a willingness to accept the merely adequate is a killer for craftsmanship. Another quote from the same chapter:

Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense on as long as you ignore the effects on the builder’s attitude and effectiveness.

In other words, good people want to build good products that they are proud of. Having worked in more than one environment where building good products was always a struggle, this is a principle I can agree with at a gut level.

The book does have some gaps. In particular, it assumes that knowledge workers should work alone or in pairs, even when part of a collaborative team – this runs counter to some of the various Agile methodologies I’m a fan of, which put emphasis on the benefits of a co-located team working in a communal area. That said, there is little in this book I disagree with, and a lot that I’m in violent agreement with.

If I could make any manager I report to read just one book, it would be this one. If I could make them read a dozen, this would be the first – closely followed by several others by the same authors (“Slack”, by deMarco, is another favourite). It doesn’t matter that some of the advice in this book is 25 years old – it’s still important.

Peopleware, Metrics, and Second-Order Effects

I bought a copy of the famous “Peopleware” book by DeMarco and Lister last week in a second-hand store. I haven’t been disappointed in it either. Anyway, in one of the chapters, they cite the infamous Glib’s Law:

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

Some time back, Jason Yip came up with a corollary to this which got dubbed (by others) as Yip’s Law:

Anything can be made measurable in a way that is inferior to not measuring it at all

This lovely piece of sarcasm is 100% accurate. As DeMarco and Lister points out, Glib’s Law does not say that anything can be measured in a way that is cheap, easy, or cost-effective. Typically, for something nebulous like productivity, what you actually end up measuring are second-order effects[1]. Now, there isn’t anything inherently wrong with this.

DeMarco and Lister make the very strong point that, for this measurements to be effective, they can not be given to management. This sits well with my experience. I, as an individual, can use impartial and incomplete metrics to highlight areas of weakness that I need to improve. Furthermore, I can do this without deliberately skewing the metric; after all, I know that the numbers aren’t fundamentally important.

However, the instant these figures get into the hands of management, they become something used to measure my productivity. I will start to have incentives to ensure that the numbers trend in a positive fashion. In other words, in order to get a better performance review (and the subsequent financial rewards), I have a strong interest in optimising the numbers. This invariably has a strong negative effect on productivity (Lines of Code, anyone?).

This is a corollory to Yip’s Law that I would like to add now:

Given the choice between not measuring and using an ineffectual measurement, management will always chose the ineffectual measurement, as long as it is cheap

The problem here is that managing by second-order effects is a management anti-pattern. People will optimise the second-order effect at the cost of the primary effect you are really interested in, and this will have serious negative effects. Using the Lines of Code example, developers start cutting-and-pasting large chunks of code rather than simply calling a method; this, in turn, causes defects to reproduce throughout the system[2], which lowers productivity because of the need to correct this. However, the impact of this on productivity can be hidden simply be cutting-and-pasting more code. 🙂

[1] A second-order effect is a symptom, not a cause. Managing via second-order effects is like placing a person with a fever due to the ‘flu into air-conditioning (or an ice-bath) to bring their temperature down.

[2] I’m really bad for cutting-and-pasting code. Whenever I do it, there will invariably be a syntax error that will prevent the code from compiling. Over the years, I’ve become convinced that this is a self-defence trick being played by my sub-concious. 😉

%d bloggers like this: