Over the last week, I saw several attacks on Apple’s new offices, responding to information from this Wall Street Journal article by Christina Passariello: a Six Colors article by Jason Snell; a Daring Fireball (John Gruber) link to Snell’s article plus a, uh, smug follow-up; and a take from Anil Dash.

What surprised me was the definitiveness with which these takes asserted that open offices are bad: for example, Dash says right up front in his headline that open offices are “something their programmers definitely don’t want”. And the reason why this surprised me is that the intellectual tradition about software development that I’ve found most informative comes to the polar opposite conclusion, that shared working space is good and individual offices are bad; and my personal experiences also hasn’t backed up the idea that individual offices are clearly superior for programming. So, while I don’t expect everybody or even most people to agree with me either intellectually or in their lived experience, seeing multiple takes claiming that it’s obvious that the opposite view is correct was a reminder of how different the worlds are that different people live in.

But hey, maybe things have changed over the last fifteen years, or maybe I hadn’t thought through the beliefs that underly my assumptions. So I figured that it’s a good excuse to write up where I’m coming from. Note, though, I am (mostly) not saying that a) people are wrong to not prefer open offices, b) open offices are a good fit for Apple, or c) Apple is doing a good job with open offices. I’m mostly just interested in sketching out the underlying assumptions behind the two points of view, to understand what is underpinning each of them.

 

With that preamble out of the way, I think this sentence from Snell’s piece is a good place to start:

Sometimes I think people who work in fields where an open collaborative environment makes sense don’t understand that people in other fields (writers, editors, programmers) might not share the same priorities when it comes to workspaces.

I’m not a professional writer or editor, but his statement there feels true to me for those fields; as a programmer, however, that statement felt bizarre. When programming, I’m working with a group of other people to produce a piece of software that I couldn’t come close to producing by myself and where I don’t want outsiders to be able to tell which parts were done by which people; to me, programming is a quintessentially collaborative field. (Yes, I realize that solo software projects exist, I’m not talking about those.) So why wouldn’t we want our environment to reflect that collaborative nature?

 

The software development methodology that I feel has worked this line of thought out the best is eXtreme Programming (XP). XP is very focused on breaking down boundaries within a team: for example, code is owned by all of the developers on the team instead of having individual developers own different parts of the code. XP also promotes fast feedback: short cycles even within your daily and weekly development rhythms, frequent releases, and frequent back-and-forth between the development side and the product side of the team.

There are a few reasons for the focus on shared ownership. One is that nobody has a monopoly on the best ideas, even in an area of the code that they know very well; so let everybody contribute. Another is that it allows ideas to pollinate, with an idea over here bearing fruit over there. A third is reducing risk: you can’t reliably figure out in advance which ideas are going to really catch on, and if you want to be able to follup on the successful ones, you want as many people as possible to be able to help; also, team composition changes, and you don’t want to be screwed over if somebody leaves the team. (This is gruesomely known as maximizing your “Bus Number”: the largest number of people who could be hit by a bus and have your product survive.)

As to fast feedback: you don’t really know how a decision will turn out (whether a micro one, like a function name, or a macro one, like a new product feature) until the decision has borne fruit: so get to that state as quickly as possible! A key point here is that product development speed isn’t necessarily the best metric: going very quickly in the wrong direction, without being able to course correct for weeks, is going to turn out less well than going at a more measured pace but being able to course correct multiple times a day.

 

As a result of this, XP explicitly recommends that the entire team (not just programmers, product people as well!) sit in a common space. From a fast feedback point of view: you can get design feedback (whether from another programmer or from a product designer) most quickly if they are literally right there next to you. And yes, that level of proximity really does make a difference: any physical distance or lag in response time noticeably increases the chance that a programmer will go ahead with what makes the most sense to them, instead of involving somebody else, I’ve seen this repeatedly.

And, from a shared ownership point of view: sitting together obviously has symbolic value. But it also means that there’s no barrier to to people working together impromptu as they discover that that’s appropriate; and it means that the natural location for design artifacts (whiteboard scribbles and the like) is in a shared space. Also, overhearing conversations means that you’ll learn something about code that you might be working on next week or even later in the afternoon; or you might overhear a conversation where you realize that you have something of value to contribute, and you can jump in.

 

The flip side of that ambient conversation is that it’s noisy, it can make it hard to concentrate. One way that XP attacks this issue is through pair programming: it turns out that two people working together can tune out outside noise (while not completely disconnecting from their environment) better than one person working solo. Also, it turns out that two people, when interrupted, can get back to full speed on their task more quickly than a single person can, because they can leverage both of their partial mental states.

And pair programming helps with the other goals that I mentioned above. It obviously helps with shared ownership, not only by making a symbolic statement but by giving a high-bandwidth route for knowledge sharing. It even helps in a more subtle way: one surprise that I had when I first started Pair Programming was that, when working with somebody else, when we got to a thorny bit, it would take us about 10 minutes to say “we should ask X for advice on this” in a situation where, when working alone, I’d probably bang my head against that same issue for an hour. And, as to fast feedback: the fastest feedback is from somebody who is in the thick of the problem with you, and pairing largely eliminates the need for a separate code review step because code reviews are instaneous.

There are other XP techniques that help with working in shared spaces, too: I’ll call out test-driven development in particular as helping minimize the negative impacts of interrupts, because it encourages you to work in a way where, at any given point, you have one very clearly stated next micro-problem that you’re trying to solve.

 

XP is a couple of decades old at this point, but I don’t think anything I’ve written above is less applicable now than it was when XP was being created. And, in terms of newer software development trends, I want to call out DevOps: more and more of us are working in a world of cloud software operated by the same teams that are developing it.

And the last thing that I want in a DevOps world is individual code ownership, with people working in isolated offices. In those (hopefully rare!) situations where something is going wrong, I want as many people as possible to swarm on the problem, attacking it in meaningful ways from different points of view, getting it fixed as quickly as possible. And it’s really hard to do that if those same people haven’t all worked together on the software in meaningful ways in non-crisis modes.

Also, from a personal point of view: if I’m on vacation, I want to be on vacation, which means that the last thing that I want to have happen is for me to be the only person who can fix a problem in a piece of code. (Or, if it’s somebody else on vacation, the last thing I want to do is to have to choose between a bad situation for our customers versus my coworker having their vacation interrupted!) I strongly advocate against individual ownership in a DevOps situation, and shared space is really helpful.

 

So, to my mind, that’s what open offices are optimizing for: collective ownership and fast feedback. Whereas individual offices are optimizing for concentration: the ability to get into flow, and the ability to hold complex problems in your head at once.

And those are obviously good things! But I don’t see them as unalloyed good. Flow is great, it helps you work at high speed; the main question I have is whether that high speed has you going in the best direction. (And also, this is an area where pair programming helps as well: pair flow is a thing.) And, if you’re working on something that’s inherently complex, then yeah, you want to be able to hold it in your head; but better still to get that task done while making it less complex, which is where incremental progress, test-driven development, and refactoring come in.

At any rate: I think that both points of view are coherent ones, and can be carried off well. As a development team, pick what you want to optimize for; as an individual, pick what matters most for you; and then make it work in the context you’re in. You don’t have to carry out either plan in all of its force for it to work, either: for example, while in general both theoretically and in my lived experience I prefer the XP ideas, the truth is that I’ve spent very little time pair programming over the course of my career, and it’s been okay, I’ve still gotten a lot out of shared ownership, incremental development, test-driven development, etc. (And I’m open to the possibility that I would be a more effective programmer if I spent more time pair programming.)

 

A postscript on the Apple-specific questions here. First, I have no idea if Apple is doing a good job with their open offices; looking at the pictures, I can see spaces that look like they’re plausibly a good size for a single development team, but who knows, and I also don’t know whether those glass walls would mean that you’re constantly being distracted by other teams or if they would end up a welcome source of light. And I have no idea how representative the few photos in that Wall Street Journal article are of the campus as a whole.

In terms of Apple’s culture: I’ve never worked there or spent a lot of time talking to people who do work there, so I have the farthest thing from an informed opinion; Snell and Gruber have a lot more info there. (Though at least I do work as a programmer, not as a writer!) But, honestly, I’m dubious of open offices succeeding as a general rule in Apple’s development culture: this is the company that publicized the notion of Directly Responsible Individual, which is pretty much the opposite of the collective ownership approach that leads to open offices. (And I’ve heard multiple anecdotes about specific pieces of software been written by individuals, too.)

So if I were in that sort of culture, and if I knew that my neck was on the line for some specific piece of code, then yeah, I might want to spend time in my office working on that code instead of talking to other people: it might not turn out as well, I might make mistakes without realizing it, but they’d be my mistakes. And I wouldn’t be able to help other people as much; that would make me sad. So, all things being equal, I’d prefer not to work at a company like Apple that loves the idea of DRIs, so I might sort myself out of Apple.

I am curious how much the above still holds in current Apple, though. For one thing, Tim Cook seems a lot more focused on collaboration than Steve Jobs seemed to have been; maybe that’s filtered down through the company. (Though I haven’t heard about the DRI concept going away.) For another thing, Apple’s software has changed with the time: they run a lot more services than they used to (which, as per my DevOps comments above, says to me that shared ownership is the right approach), and clearly their OS development is much more incremental than it was a decade ago, with a regular yearly cadence and with significant changes appearing even in point releases. So it wouldn’t shock me if there are increasing numbers of software development teams within the company that prefer open working spaces.

 

Some Twitter thoughts from others that struck me:

Post Revisions:

This post has not been revised since publication.