Open Plan Alternatives: Gleaming the Cube

In my last post, I urged office planners to ask their people what kind of environment is best for them. One surprising thing they might hear is that people prefer—gasp!—cubicles. Yes, cubicles.

In the hundreds of comments people have written on my various blog posts about office design, a common theme was of people working in open plans who wished they could have their cubicle back.

In fact, I was surprised when an interview I did with Wired regarding my views on office design was boiled down to a statement I made to this regard:

I’ve heard from several people who were incredulous that anyone could prefer a cubicle to an open plan. I believe this attitude may be a kind of extreme reaction to the giant, soulless “cube farm” that some companies employed (and still employ).

But, an open plan can turn into a landscape just as depressing when applied uniformly to a large space.

We can compromise, right? The Library and the Bazaar can coexist. It’s not an all-or-nothing proposition. And please don’t assume that everyone hates cubicles. It’s no private office, but for many people it beats the hell out of the open plan.

Open Plan Alternatives: Ask Your People

I’ve heard from several people who have the power to make decisions about office space, but feel frustrated that they can’t find practical suggestions on what to do instead of an open plan.

Well, if you’re already open to the idea that open plan offices are not a panacea, but you don’t know what to do instead, here’s a surprisingly straight-forward suggestion: ask the people who work there.

If there’s one thing I’ve learned throughout my writings on office design, it’s that people who work in offices have strong opinions about how they’re designed. The only thing that holds them back from expressing their opinions is a sense of learned helplessness that comes from years and years of working in crappy offices and seeing that no one cares about improving the situation.

This point was buried in another post I wrote regarding open plans, but here it is again: No size fits all. I’m sorry, but you’re going to have to consider the people who work for you as individuals with different wants and needs, because, well, they are.

I’ll end on a quote from Peopleware, as I often do…

A common element that runs through all the patterns (both ours and Alexander’s) is reliance upon non-replicable formulas. No two people have to have exactly the same work space. … The texture and shape and organization of space are fascinating issues to the people who occupy that space. The space needs to be isomorphic to the work that goes on there. And people at all levels need to leave their mark on the workplace.

Integration Is Communication

Kent Beck wrote a tweet recently that had me nodding my head:

I feel like this is a lesson one only learns while working for a large corporation. At this scope, there’s so much work to be done, and so many groups of people involved, that the most acute pain is always felt at the integration points.

The obvious solution is “better communication.” More meetings, more emails, more documentation, more complicated forms one group fills out to communicate its needs to the others. The cure seems worse than the disease.

What’s the real solution? I’m not sure there is one.

Martin Fowler, Perks, and Remote Work

In my post, Remote Work Denial Is a Bad Look, I argued thusly:

You can think face-to-face, in-person communication is most efficient, and I won't argue with you, but it ultimately doesn't matter as the remote work trend will not be stopped.

Figure out how you're going to make remote work effective for your company and then shout it from the rooftops.

In a recent article, Remote versus Co-located Work, Martin Fowler presents a level-headed take on remote work in which he arrives at roughly the same conclusion:

Most groups of people will be more effective when working co-located due to the richer communications they have.

Despite the fact that I think most teams would be more productive working co-located, you will often get a more effective team by embracing some form of distributed model because it will widen the talent pool of people you can get.

The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing. I sense a growing reluctance amongst the best developers to accept the location and commuting disadvantages of single-site work. This is increasingly true as people get more experienced, and thus more valuable. You can either try to ignore this and accept the best people who will relocate for you, or you can explore how to make remote working patterns more effective. I think that organizations that are able to make remote working patterns effective will have a significant and growing competitive advantage.

Remote work is certainly not easy to get right, but it is nevertheless possible, and it represents a very desirable perk. Just as you could easily make the argument that it’s silly for employers to be responsible for the health insurance coverage of the people that work for them, try going out and hiring great people while telling them that you don’t offer health insurance (and good health insurance). How long will it be before companies have a similar difficulty hiring good knowledge workers because they don’t offer the perk of remote work?

The Yacht Metaphor for Software Organizations

I’m big on metaphors, and I’ve always loved Joel Spolsky’s software-organization-as-yacht metaphor:

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don't steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

“That’s Easy. You Just…”

On a recent Hacker News submission about the phenomenal success of WhatsApp, I clicked through to the comments thread, and read the top comment:

> Why WhatsApp Only Needs 50 Engineers for Its 900M Users

Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.

There’s some kind of disease in the tech world about trivializing the accomplishments of others, and conversely about understating the effort one took to achieve one’s own accomplishment.

There’s a person I call the “That’s Easy. You Just…” Developer. He wants you to believe that software is easy and obvious.

My Weekend Project

If you’re a regular HN reader, you may recognize the common “Show HN” posts where someone seeks feedback on a project they’re doing. “My weekend project”. People like to suggest that it only took them a weekend to produce the thing they’re now showing off. When you build something in a weekend, it’s typically worth about a weekend’s worth of time. More impressive is, “Look what I built in 10 years.”

Boss, That’ll Take About Five Minutes

In an attempt to win technical arguments, a developer will sometimes trivialize the difficulty of the thing they want: “That’ll take about five minutes.”

As professional developers, we know that nothing takes five minutes to ship and recognize the exaggeration for what it is. The problem is, non-technical people hear this trivialization and occasionally take it to heart. “These guys keep talking about how that would take ‘about 5 minutes.’ Software is pretty easy, I guess.”

Cheating on the Definition of Done

A common hack is to cheat on your definition of done. Despite your overall feeling of Scrum as a methodology, I think one thing they nailed is the importance of getting precise about the definition of done.

Rule of thumb: a flurry of code at 2AM usually does not result in something that’s done.

Obviously…

It’s easy to pretend that something you know now was obvious. I’ve given in to the temptation to treat a momentary advantage in knowledge over someone as an opportunity to pretend that knowledge was obvious to me all along. In fact, I still feel like a jerk looking back at the times I’ve done this. “Oh you need to do X, just use Y. Duh.”

It’s okay to admit that things are hard, that maybe you felt dumb yourself when you were learning it. The secret is, we all actually know it’s hard, but we won’t admit it.

Backlog Prioritization Affects Developer Morale

If you read Scrum literature, you may get the idea that the Product Owner is a kind of dictator of the product backlog, in that he or she unilaterally decides the priority of work remaining on a product and passes this order down to the development team.

Author of All About Agile, Kelly Waters, has this to say:

Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive.

But… very importantly – only the Product Owner can prioritize the Product Backlog.

As I mentioned in my last post, there is a ton of writing out there about Scrum and Agile methodologies, and it is definitely possible for someone to come to Scrum with preconceived ideas about how software should be made, and then find justifications in the writing.

I want to make the point here about the importance of development team input into backlog priority.

In particular it’s very easy for a Product Owner to dismiss technical debt or other concerns that typically only the developers grumble about as less “sexy” than delivering another feature to end users.

When the decision comes down to fitting one more new feature into a sprint or paying off some debt on code quality, the decision usually goes to the former. But as the authors of Peopleware discuss, managers need to keep in mind the importance of quality to makers, above and beyond just immediate market concerns:

We all tend to tie our self-esteem strongly to the quality of the product we produce—not the quantity of product, but the quality. (For some reason, there is little satisfaction in turning out huge amounts of mediocre stuff, although that may be just what’s required for a given situation.) Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you.

The hard-nosed, real-world manager part of you has an answer to all this: “Some of my folks would tinker forever with a task, all in the name of ‘Quality.’ But the market doesn’t give a damn about that much quality—it’s screaming for the product to be delivered yesterday and will accept it even in a quick-and-dirty state.” In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.

Scrum expert, Mike Cohn, also discusses times when developers should be given leeway to decide their own priorities, including when they just need a break from the same old same old:

On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.

Product owners, please remember to incorporate the feedback of your development team into prioritization, as it has real effects on their morale. And unhappy developers will tend to leave your project for greener pastures.