gears
within
gears

I was re-reading Joel Spolsky’s Field Guide to Developers recently, and while ruminating on his usual mix of striking insight and infuriating nonsense I got to thinking about why it is, exactly, that open team spaces work so well. Joel is right that cubicles suck, and if offices are working for his company then I’m happy for him and for his employees. But he’s limiting his data input in a pretty dramatic way if that’s all they’ve tried. Given a choice between isolating myself from my team or enhancing the effectiveness of my team space I’ll take the latter every time.

Writing successful software isn’t even mostly about cranking out great code, though that part is certainly important. It’s about working with people to build something people want to use, and in order to communicate effectively people need lots of talk bandwidth, preferably of the face-to-face kind. High-functioning teams prefer working in team spaces not because they can’t afford swanky offices, but because team spaces and pair programming are far, far more productive than offices. If you’re starting a company, for goodness sake, don’t spend all your money building silos that just happen to look like offices. Build a great team and keep them together, in the same room, for as long as possible.

Noise is golden

The most important thing you can do to encourage your team to stay together in the same room is to promote a culture of pairing on programming tasks. When I work alone, without a pair, I find it easy to get distracted, and so I try to foster an environment that minimizes distractions. In other words, I use headphones. But I prefer working in pairs, because when I do so I find it much easier to stay on task, and so I try to foster an environment that maximizes team communication. It is the missing piece of the puzzle that makes team rooms not just possible but desirable. Pairing is a great way to work precisely because you don’t need crutches to help you focus, and once you’re freed from that concern it opens you up to other ways of collaborating.

If you’re trying to encourage an environment that allows talented developers to recline in splendid isolation eight hours a day then you’re doing it wrong, and not just because it takes more than developers to build great software. By the same argument that’s typically made for Aeron chairs, isolation is penny-wise and pound-foolish; cacophony may be distracting, but it won’t stop a team dead in its tracks anything like the way silence will. That’s why agile teams participate in morning stand-up meetings even though they generally work in a team room anyway: not because they expect that, on any given morning, they will glean some kind of deep insight about the state of the project, but because simply providing an opportunity for serendipity-a question about a bug, an offhand comment about an upcoming requirement-redounds in surprising ways. We have short boring meetings now so as to avoid long stressful ones, the ones you’ll have six months from now when you figure out what you missed.

Thanks to to Dan North, who gave me valuable feedback on this post: “It’s fine,” he said, “just post the damn thing.”