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.

• By Mike Gunderloy
• 08/01/2001

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.

Book Information Peopleware: Productivity and Teams By Tom Demarco and Timothy Lister Dorset House $33.95, ISBN 0932633439 Extreme Programming Explained By Kent Beck Addison-Wesley $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 Spoils
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:

1. 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.
2. 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!
3. 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.
4. 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 other ways.

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.