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.”

Desi McAdam and Jim Remsik of Hashrocket recently got featured in a New York Times article on he practice of pair programming. It’s wonderful that they believe so strongly in the practice and devote so much time and attention and money to hiring great people and providing them with a world-class work environment, but I thought Obie’s followup really excludes folks who might otherwise get a lot out of it. Hashrocket’s setup provides an optimum environment for pairing, but the folks who first came up with the practice didn’t have that kind of workspace available everywhere, and you don’t have to, either. Here’s five things I thought Obie missed.

5. Pair Programming Doesn’t Require Expensive Hardware

All it requires is a computer you’re willing to treat as a shared workspace. Ideally it should be as powerful as a standard developer workstation. If you’d like to, use a dedicated account on one pair’s laptop. Many IT departments already have spares of everything else-keyboards, monitors, and mice-locked away in a storage room somewhere.

If your workspace is configured for cubes, see if you can borrow a conference room for a few days, until you can decide if you like it or not. And as for me, I program in pairs all day but my desk chair of choice possesses neither bells nor whistles. As with everything else, a good manager should treat you with respect and provide you with the tools that you need to get your job done. But that doesn’t mean that they owe it to you to rip apart your entire office if you decide you’d like to start trying to pair a little bit more.

4. Everybody Need Not Get Together And Love One Another Right Now

Not everyone has to get along to get a lot out of it. If two people don’t play nice then don’t pair them together all that often. It might be unpleasant for some managers to have to enforce certain basic hygiene practices, and it might lead to some uncomfortable conversations. But it seems unlikely that it would result in a major shift, as most workplaces already do this.

3. Many Businesses Are Happy To Try Pairing

In more than two years working at ThoughtWorks I’ve never been on a project that didn’t consist of 100% pair programming, though that’s not the case for all of our projects. But my experience has been that we treat pairing as simply part of a well-run Agile project and we expect our clients to recognize and respect that, and virtually all of them have come around to the opinion that it’s something they should be encouraging in their own enterprise. As part of those projects I’ve paired many non-ThoughtWorks developers from more conventional IT backgrounds and I’m proud to have worked with all of them.

2. Many Software Shops Care Deeply About Return On Investment

This isn’t exactly contradicting Obie’s point. But whereas not every IT shop might care about excellence per se (although I think he might be selling some folks short) they all, from the smallest boutique shop up to largest enterprise business unit, care about spending their IT money wisely. Pair programming makes good business sense: it cuts down on defects, raises productivity and helps you spread technical knowledge radically faster than ever before.

1. Pair Programming Is Not Just For The Elite

You do not have to be an incredibly hardcore developer to enjoy it or want to try it. It will make most developers, whether they be great or small, young or old, or male or female, happier and more productive. If you tried it and decided it wasn’t for you, then fair enough. But everyone a little bit of curiosity-especially those who think it couldn’t possibly work for them-should give it a shot. It’s just a nicer way to work.