Don't overlook the role your physical space plays in the software that you create.
Improve Your Environment
Don't overlook the role your physical space plays in the software that you create.
Almost 15 years ago, Tom DeMarco and Timothy
Lister studied programmer productivity in a variety of
environments. They came to the conclusion, based on their
own work plus data from such places as IBM and Bell Labs,
that developers produced more and better code in offices
than in cubicles. They suggest that this is directly related
to the ease (or difficulty!) of getting into a "flow"
state where you get deeply involved with the task at hand.
In their book Peopleware: Productivity and Teams
DeMarco and Lister address employers:
In most of the office space we encounter
today, there is enough noise and interruption to make
serious thinking virtually impossible. More is the shame:
Your people bring their brains with them every morning.
They could put them to work for you at no additional
cost if only there were a small measure of peace and
quiet in the workplace.
DeMarco and Lister recommend private offices
with doors for developers, a bit of wisdom that has been
endorsed by many writers since even as cubicles have become
ever more the norm.
Productivity and Teams
By Tom Demarco and
$33.95, ISBN 0932633439
Extreme Programming Explained
By Kent Beck
$28.95, ISBN 0201616416
On the other hand, Kent Beck takes a different
view in Extreme Programming Explained. His style
of software development involves lots of teamwork, and
he argues that you need a workspace that facilitates teamwork.
He likes bullpens with large tables for the computers,
little cubbies for personal space, and a communal relaxation
space with toys and a coffeemaker. And of course he can
back his ideas up with data about how much more productive
it makes developers as well.
Which Approach Is Better?
So, have things really changed that much in 15 years?
Nope! DeMarco & Lister and Beck come to different conclusions
about workable space because they have different models
of software development in mind. If you're writing a constrained
piece in a large architecture and need to concentrate
to get a tricky algorithm perfect, you want an office
with a door that closes and a lack of hubbub. If you're
using pair programming and other XP techniques to blast
through rapid iterations of code, then getting a good
team together where they can develop some synergy is essential.
But all three authors have the same attitude towards facilities.
Here's a bit from Beck's book:
If the corporate attitude towards facilities
is at odds with the team's attitude, the team wins.
If the computers are in the wrong place, they are moved.
If the partitions are in the way, they are taken down.
If the lights are too bright, they are taken out. If
the phones are too loud, one day, mysteriously, they
are all found to have cotton stuffed in the bells….
All this screwing around with furniture can get you
in trouble…. I say, "Too bad." I have software to write,
and if getting rid of a partition helps me write that
software better, I'm going to do it. If the organization
can't stand that much initiative, then I don't want
to work there, anyway.
So why, fifteen years after we learned that
facilities design makes a difference to software productivity
and quality, do so many of us still work in frankly inadequate
spaces? There are, I think, two reasons for this. First,
it's easier to see the cost of good facilities than it
is to see the cost of bad facilities. Second, we get our
sense of pecking order mixed up with everything we do.
Rats in a Maze
At one point, I took a consulting contract to help a small
team within a large organization with a Y2K remediation
project. Their workspace was drearily typical of corporate
America: acres of identical cubicles. Well, not quite
identical. For reasons known only to themselves, the facilities
people moved partitions around from time to time, creating
little workgroup islands or rearranging corridors. As
a new visitor, I needed a native guide to find anything
for the first week or two. Even after that, it was perfectly
possible to turn a corner on a route you were used to
and find a blank wall in front of you.
But it gets better than that. There was little
attempt to keep groups together. The corporation had barely
enough cubicles for all the workers, so when someone new
was hired, they were slotted into the first available
cubicle. That meant, in most cases, they were nowhere
near their "team." In the case of the folks I was working
with, we were spread out over several buildings, with
a long walk for some people to the shared conference room.
You can imagine how rarely we saw each other in person,
and how hard it was to stay in touch with the whole project.
Not surprisingly, coordination was difficult or impossible,
and it was not unusual for work to fall in the cracks
or be duplicated.
Now, I'm sure the facilities folks could
have shown us numbers on how much money this rat-in-a-maze
approach saved, compared to actual offices or even bullpen
settings. And I'm sure it was much cheaper to scatter
folks willy-nilly, instead of adding some extra space
and keeping groups together. But I'd guess that every
dollar saved on space in that corporation wasted at least
ten dollars in developer salaries. Little wonder that
the project did not go well.
To the Managers Go the
As an example of my second factor, I think back to one
of the first jobs I had, with a large computer manufacturer
(since gone bankrupt) at the very start of the PC revolution.
The company had been around long enough that everything
from the chair you got, to whether you got a cubicle or
an office (and whether the office had a door or a window,
how many chairs you got for visitors, and so on) was rigidly
set in the company hierarchy. Get a promotion, get a bigger
office. Get another promotion, you actually got a PC on
your desk. Yes, the computers went to the managers first.
The group I happened to be working for at
the time was responsible for programming the machines
that stuffed integrated circuits into circuit boards to
make the PCs. We used punched paper tape (I know, I'm
dating myself) to move programs from our office area to
the shop floor. After some research, we decided that we
could improve production by putting in a PC and using
a rudimentary network to program the shop floor machines,
disposing with all that abysmal paper tape.
Well, you guessed it. We weren't upper-level
managers, so we couldn't get a PC. It didn't matter that
it would improve productivity; the prestige rules said
we couldn't have one. Fortunately for that company, we
found an innovative solution: one weekend we swiped the
guts out of the division manager's PC, found a spare monitor
and a spare power supply, and breadboarded our own production
machine. Since the division manager never actually turned
on his PC, this worked out to be an ideal solution.
So, what's the lesson here? I think there
are several things to learn from what we know about space
design for developers:
- Space matters. There's no one-size-fits-all
solution; the bottom line is that developers produce
better software when their workspace is appropriate
for their methodology, whether that means private offices
or bullpens. But five-foot-high anonymous cubicles do
not seem to be good for any development method.
- In many cases, we're stuck with bad space
because we haven't been able to make an argument for
good space. If there are concrete improvements that
can be made to your working space—perhaps elimination
of an extra wall, a more comfortable chair, or a less-obnoxious
phone—it's worth documenting, as best you can,
the effect of the poor facilities on your work. If you
keep track of time wasted running through the maze to
find a co-worker, time lost getting back into the flow
after the obnoxious phone rings, and so on, you might
be able to convince a reasonable boss to fight with
the corporate facilities people on your behalf.
Of course, this can be a dangerous
tactic in these downsizing times—sometimes the
squeaky wheel gets removed from the axle entirely!
- An alternative to squeaking is to keep
your eyes open for opportunities to get into better
conditions. You can play the corporate politics game
to be the first one into new office space if you're
good at it, but most developers I know are at best naïve
about corporate politics.
A better bet is usually to
keep tabs on new projects within the company. There's
usually some manager or other about to embark on a technology
exploration or proof-of-concept or evaluation of a new
methodology to see whether it works. If you can find
the right project, you can help make the case that a
"skunk works" approach, where they turn the team loose
in an offsite, non-standard space, offers the highest
chance of success. And once you get into such a space,
you can be very hard to pry out.
- If all else fails, resolve to make space
an issue at your next job. When you're interviewing,
make sure you see the space where you'll be working,
not just the manager's office. If it's plainly inadequate,
and you can afford to negotiate, let them know that
you'd love to take the job, but not if you can't deliver—and
you can't work under those conditions.
It's easy to get caught up
in technology excitement during the interview process.
But remember: technology changes faster than office
space. If you take the time to find the best space up-front,
the technology you want to work with will likely come
along later. And good offices are a good indication
that the organization will treat its people right in
What do you think? Are you in your dream
work environment, or does your cubicle prevent you from
writing code? Do you have your own tales of guerilla workspace
changes? Drop me a line and let me know; I'll print some
of the best stories in a future column.
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.