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.
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
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
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
- 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@example.com
to let me know! Comments may be used in a future issue of Developer Central,
unless you ask me to keep them confidential.
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.