PeopleWare: Your Father's Software Development?

It's not quite back to programmers riding scooters through office halls, but this software management style can pay off in increased productivity.

• By Mike Gunderloy
• 03/01/2002

Tom DeMarco and Timothy Lister wrote Peopleware in 1987. The second edition, featuring eight new chapters, came out in 1999 from Dorset House Publishing. The book is based on research that started in the early '70s, making some of the stuff here more than a quarter-century old. That's a long time in programmer years. I seem to recall we were programming with pointy sticks and clay tablets back then, but the memories are pretty hazy.

Anyhow, is there anything for the hot-shot, latte-drinking dot-com developer generation to learn from this book? Amazingly enough, the answer is yes! This book is a classic of the field of software management, and at just over 200 pages it should be required reading for any team leader or manager.

Note that this is not a programming book. The subtitle here is "Productive Projects and Teams." What DeMarco and Lister are concerned with is the fact that the ratio in productivity, by almost any measure, between different teams is 10 to one in the software industry. Put another way, the best teams can build in a year what the worst teams take a decade to do. And this doesn't seem to be just a matter of the best teams having the best programmers (though the best programmers do tend to gravitate to the companies that have an environment that encourages good teams). So what's the difference?

DeMarco and Lister argue that the difference is that the good teams have a good working environment, aren't subject to ridiculous nonsense that doesn't contribute to developing software, and have managers who stay out of the way (and, if necessary, that manager may run interference to keep other people out of the team's way). Along the way, they talk about the stultifying effects of Big Methodologies, the necessity of offices with doors and windows rather than those odious cubicles, having fun at work, the necessity of some chaos, and why some organizations can learn and others can't, among other things.

Beware the Furniture Police
Many of the problems that the authors identify boil down to management treating developers as if they were cattle, rather than people who use their brains for a living. For example, the authors devote several sections to skewering the Furniture Police, who are (sad to say) found in any major corporation. If you've ever worked in a cubicle farm, this might ring a bell:

Basement space is really preferable from the point of view of the Furniture Police, because it lends itself more readily to uniform layouts. But people work better in natural light. They feel better in windowed space and that feeling translates directly into higher quality of work. People don't want to work in a perfectly uniform space either. They want to shape their space to their own convenience and taste….The very person who could work like a beaver in a quiet little cubbyhole with two large folding tables and a door that shuts is given instead an EZ-Whammo Modular Cubicle with seventy-three plastic appurtenances. Nobody shows much interest in whether it helps or hurts effectiveness.

Fortunately, this is one area where things have changed for the better, at least in some organizations. Microsoft is notorious for "wasting money" on things like offices with doors and windows for developers, free drinks, lounging areas, and other such nonsense. The result? Microsoft people actually like being in the office, for the most part, and are free to concentrate on writing good quality code. In fact, Joel Spolsky has argued that one of the reasons for Microsoft's success is that Bill Gates built an entire company full of managers who've read Peopleware. Joel recommends that software managers re-read the book once a year—not a bad idea. (Check out Joel's Web site at http://www.joelonsoftware.com/navLinks/fog0000000262.html.)

The Furniture Police are just a symptom of a larger problem that turns up in many guises. The problem is that a misplaced sense of efficiency leads to cost-cutting measures that actually cost money in the long run because they impede team building and software development. A few other examples:

• Those odious "motivational accessories" (you know, the ones with some full-color photo and a phrase like "Giving Your Soul to the Company is the Highest Good") that are substituted for real motivators (like higher pay or offices with doors) by penny-pinching middle management.
• Institutional adherences to process improvement programs (most notably the Capability Maturity Model) that concentrate on making your process efficient while removing all consideration of whether you're efficiently producing anything the market wants to buy. If the CMM were reflected in the real world, perfect mud pies would sell for more than flawed coconut cream pies.
• Teams that get scattered all over the corporate campus because it's too much trouble for the facilities people to find them a single set of offices in one contiguous block.

You get the idea. The problems are legion, and DeMarco and Lister fearlessly catalog many of them.

The Magical Flow State
Rock-climbers enter a state called "flow" while they're concentrating, in which moving up the rock seems effortless and timeless, the entire body is involved in the climb, and everything comes together perfectly. Of course, much as we'd like to pretend otherwise, software development isn't really like rock-climbing. For one thing, when our code falls down it doesn't tend to cause compound fractures. But we do share one thing: the flow state. Many words have been written trying to describe this state. Fortunately, I don't have to add to them. If you've ever done serious software development, uninterrupted by petty nonsense, you know what flow feels like. It not only feels good, it leads to good code.

Flow is the thing that management tends not to understand, the reason that the Furniture Police are allowed to dictate your working environment. As DeMarco and Lister point out, this is completely understandable, because most management is naturally interrupt-driven. Management is the very art of responding to endless interruptions. Unfortunately, software development isn't. After a five-minute phone call it takes most developers 15 minutes or more to get back into a flow state. If the five-minute phone calls come once every 12 minutes, you're doomed.

As an aside, I'd love to see some serious research on whether outstanding programmers get into a flow state more quickly than others. My hunch is that they do. I also suspect that they can maintain a deeper stack of interruptions without losing track of what's at the bottom of the stack. Of course hunches are much easier to come by than proof.

Bear in mind, though, that it's not just the mysterious and oppressive Them that keep developers out of a flow state. We also do it to ourselves. If you have trouble getting there, try shutting down your e-mail client for a few hours. The world won't come to an end, and you won't have that niggling interruption hitting you every 30 seconds.

But What About Us Independents?
If you've gotten the impression that Peopleware is based on experiences with software teams at large corporations, you're right. In these "new economy" days, there are an awful lot of us writing software in corporations where the staff can be counted on your fingers, even if you include the cats and dogs. Despite that, I think this book still has a few things to offer the independent developer.

First off, if you're having one of those days where you think corporate wage-slavery might be preferable to yet another round of phone calls to shake money out of dilatory customers, reading about the bad management nonsense here may give you renewed energy for being out on your own. More important, though, independents are their own managers. We're not immune from setting up our own offices in such a way that it helps us fail. Is your toddler underfoot for hours during the working day? Do you have a ballgame on the television for background noise? Just how much time did you spend on Web-surfing today, hmmm? Recognizing—and removing—the homegrown impediments to flow can help you deliver more value to your clients, and ultimately raise your billable rate.

Finally, it's the rare independent developer who never spends time in a corporate setting. Understanding the principles set out in this book can help you make better use of your time out in the field. If you're writing a boilerplate contract, for example, you should specify that you'll be given a working area with a desk, chair and door. If the client balks at that, the warning bells should go off in your head. Find another job or, at the very least, raise your rate.

A Fun Read
If you've already read Peopleware, now what? Two suggestions. First, it's worth dropping by the Web site for the Atlantic Systems Guild (http://www.atlsysguild.com/), a company which the authors helped found. Second, read it again! Face it, this book is just plain fun, and I was happy for the excuse to dip back in when writing this column. Really, how often do you get to read gems like this:

When bosses are particularly needy, the burden of ceremonial status meetings can grow almost without bound. We know of one organization, for example, where daily two-hour status meetings are the norm. When participants are off-site during a meeting, they are expected to call in and participate by speakerphone for the whole duration. Nonattendance is regarded as a threat and is subject to serious penalties.

You won't find a single line of code in this book. But if you're managing a team, you'll probably find that listening to DeMarco and Lister will help get a lot more lines of working code into the final product more quickly than ignoring them will.

Does your boss get it? Or are you thinking of leaving an anonymous gift of Peopleware on his desk? Write me at [email protected] to let me know! Comments may be used in a future issue of Developer Central, unless you ask me to keep them confidential.