“There are a million ways to lose a work day, but not even a single way to get one back.”

“How does a large software project get to be one year late? Answer: One day at a time!”

It’s trendy right now to produce office space that looks like an Apple store. Bright, airy, cheerful, lots of open space, big ceilings, blonde wood, attractive and friendly employees. I can’t blame the urge – I love seeing the latest architectural masterpieces the geniuses at Apple routinely cook up. Living in New York I have the opportunity of being a short hop away from no less than five of them.

Apple retail stores invoke the sprits of great cathedrals of the 14th century or some vast ancient library. If you’ve ever stepped foot into one, however, the library or cathedral-like comparison vanishes into the cacophony of hundreds of conversations, various iTunes-sponsored music clips, and the ringing of countless iPhones. Often when I walk into one of these stores I’ll put on my noise-isolating earbuds – not to listen to music, but to act as earplugs.

So why is it that companies – small and large, startup and established player – continually take high-pay, high-skilled, super-smart programmers and cram them into giant rooms full of noise and distraction?⁹

Examples are everywhere: AppNexus – Klout – Kiva – ZeroCater – JustinTV – PublicStuff

Things you’ll notice in virtually all of these include: folks talking on phones, people listening to headphones, small groups standing and talking, and the deafening sound of thousands of dollars of productivity being sucked out of the room.

Go to any of these offices and ask each programmer: how often are you distracted? Do you ever find yourself drawn into conversations that you aren’t a part of?

I interviewed at a company that had a giant office (imagine a hundred folks in one room) and one of their engineers proudly said: “We have a generous work from home policy. I love it because I can never get any work done around here!”

Flow

Programmers work in a state of “flow”¹ – it takes a tremendous amount of mental wrangling to page in to memory all the data required to comprehend the micro and the macro of software systems. Recalling the object hierarchy, database schema, or GUI architecture for a complex system is akin to building a house of cards. One slight bump and the whole thing comes tumbling down.

Some estimates have suggested it takes 15-30 minutes or more² to get in the zone³. What is less-known is how long it takes to re-start flow once you’re knocked out. Given an average NYC fully-loaded salary, a simple email “Ding!” or an answer to a “quick question” could cost a company $50.

Of course, it is too simplistic a measure and vastly underestimates the true cost of distraction⁴; many larger features or architectural decision-making requires continual effort to maintain progress. A few interruptions strategically placed through the course of a day could make a four-hour task take two days.

Sure, large companies are so full of inefficiencies and waste that the lack of agility won’t hurt them. But startups? If your programmers are less efficient than the competition that could mean you launch months late. That you can’t iterate as quickly as you need. And that next amazing idea – that idea that fundamentally transforms your company and changes the world – simply doesn’t have the time and focus to exist. It’s lost in the noise.

Solutions

The evidence is pretty clear that massive open-plan offices where the entire office is colocated are terrible interruptors of programmers⁸. At the the other extreme we can place programmers in private offices (with a door that actually closes!) to keep them isolated from the noise and movement of the office.

DeMarco and Lister, via Peopleware⁷, argue for private offices for each developer because most software development is done in isolation.

“Agile” methodology, on the other hand, states that communication is the most important factor and that private offices destroy communication¹². Oram and Wilson, via “Making Software: What Really Works and Why We Believe It” argue very strongly that the Communal Workshop (smaller units of open-plan with, say, six or seven programmers in their own room) layout is the most efficient for teams that require lots of collaboration and have loose requirements.[Oram and Wilson, pg. 346]¹²

As a counterpoint, Joel Spolsky suggests that communication isn’t harmed via private offices.^{10 11}

There are valid points to each solution but I’m not aware of any hard data that can conclusively determine the “victor”, if there is such a thing.

Regardless of the layout, here are some rules that must be enforced:

Create a quiet workplace free of unnecessary distractions

Some distractions, like going to lunch or pair programming, are necessary. Most distractions, like ringing cell phones, conversations not involving the team, eating lunch, and playing music are unnecessary and disruptive.⁵

Keep ambient noise to a minimum

At our office, we have a shared space where the developers work and everyone else is in a separate location. We treat the programmer space as we would a library. No irrelevant conversations⁶, don’t bother anyone, stick to IM and IRC whenever possible. Meetings either are team-wide (standups), so can take place in the shared space, or individual, and are taken out of the room.

Leverage Technology

We use group chat with logging, private instant messaging, wikis, blogs, etc. to keep general chit-chat down. The side effect, too, is that two programmers can have a discussion in a chat room and any passive bystander can chime in if they feel like. If they’re busy or not in the office, they should browse the chat log upon returning to work. As they catch up, they can re-engage the other programmers if they choose.

No meetings

The more meetings a programmer has the less time they have to work. We only have one meeting, our daily standup – everything else is ad hoc and optional.

Conclusion

With a little bit of time, thought, and effort, we can have office space that is much more enjoyable, productive, and focused on programmer happiness.

Footnotes