Skip to main content

Office Space

How important is the physical workspace to knowledge workers generally,and software developers specifically?  Everybody agrees it'simportant.  Talk to ten people, though, and you'll get nine differentopinions about what aspects are important and how muchthey impact effectiveness.  But there are some classic studies thatshed some light on the subject; looking around recently, they haven'tbeen refuted.  At the same time, a lot of people in the softwareindustry don't seem to have heard of them.

Take the amount and kind of workspace provided to each knowledgeworker.  You can quantify this (number of square feet,open/cubicle/office options).  What effects should you expect from,say, changing the number of square feet per person from 80 to 64?  Whatwould this do to your current project's effort and schedule?

There's no plug-in formula for this, but based on the available data,I'd guesstimate that the effort would expand by up to 30%.  Why?

"Programmer Performance and the Effects of the Workplace"describes the Coding War Games, a competition in which hundreds ofdevelopers from dozens of companies compete on identical projects. (Also described in Peopleware: Productive Projects and Teams.) Thedata is from the 1980's, but hasn't been replicated since as far as Ican tell. The developers were ranked according to how quickly theycompleted the projects, into top 25%, middle 50%, and bottom 25%.  Thecompetition work was done in their normal office environments.
  • The top 25% had an average of 78 square feet of dedicated office space.
  • The bottom 25% had an average of 46 square feet of dedicated office space.
  • The top 25% finished 2.6 times faster, on average, than the bottom 25%, with a lower defect rate.
  • They ruled out the idea that top performers tended to be rewarded with larger offices.
Now, whether larger workspaces improve productivity, or whether moreproductive people tend to gravitate to companies with largerworkspaces, doesn't really matter to me as a manager.  Either way, theanswer is the same: Moving from 46 square feet per person to 78 squarefeet per person can reduce the time to complete a project by a factorof up to 2.6x.  That's big.  (Of course there were other differencesbetween the environment of the top 25% and the bottom 25%, but they arelargely related to issues like noise, interruptions, and privacy.  Itseems reasonable to assume these are correlated with people density.)

It itself, this doesn't give us an answer for the question we startedout with (changing from 80 square feet to 64 square feet per person,and bumping up the people density commensurately).  As a firstapproximation, let's assume a linear relationship between dedicatedarea per person and productivity ratios.  64 is just over halfwaybetween 46 and 78, so it seems reasonable to use half of the 2.6factor, or 1.3, as a guesstimate.  So using this number, a project thatwas going to take two weeks in the old environment would take 1.3 timesas long, or around two and a half weeks, in the new environment.  (Inthe long term, of course.)

To put this into perspective, it appears that increasing an organization's CMM level by one generally results in an 11% increase in productivity, and that the ratio of effort between worst and best real-world processes appears to be no more than 1.43.

You can't follow the numbers blindly here.  This probably depends a loton the kind of work you actually do, and I can think of dozens ofcaveats.  My gut feeling is that the penalty is likely to be more like10% than 30%, assuming you're really holding everything else (noise,interruptions, etc.) as constant as possible.  I suspect that theorganizations which are squeezing people into ice cube sized cubiclesare likely to be destroying productivity in other ways as well.  But,these numbers do provide some guidance as to what to expect in terms ofcosts and consequences of changing the workplace environment.

Links and references:


Popular posts from this blog

Personal Web Discovery (aka Webfinger)

There's a particular discovery problem for open and distributed protocols such as OpenID, OAuth, Portable Contacts, Activity Streams, and OpenSocial.  It seems like a trivial problem, but it's one of the stumbling blocks that slows mass adoption.  We need to fix it.  So first, I'm going to name it:

The Personal Web Discovery Problem:  Given a person, how do I find out what services that person uses?
This does sound trivial, doesn't it?  And it is easy as long as you're service-centric; if you're building on top of social network X, there is no discovery problem, or at least only a trivial one that can be solved with proprietary APIs.  But what if you want to build on top of X,Y, and Z?  Well, you write code to make the user log in to each one so you can call those proprietary APIs... which means the user has to tell you their identity (and probably password) on each one... and the user has already clicked the Back button because this is complicated and annoying.

XAuth is a Lot Like Democracy

XAuth is a lot like democracy:  The worst form of user identity prefs, except for all those others that have been tried (apologies to Churchill).  I've just read Eran's rather overblown "XAuth - a Terrible, Horrible, No Good, Very Bad Idea", and I see that the same objections are being tossed around; I'm going to rebut them here to save time in the future.

Let's take this from the top.  XAuth is a proposal to let browsers remember that sites have registered themselves as a user's identity provider and let other sites know if the user has a session at that site.  In other words, it has the same information as proprietary solutions that already exist, except that it works across multiple identity providers.  It means that when you go to a new website, it doesn't have to ask you what your preferred services are, it can just look them up.  Note that this only tells the site that you have an account with Google or Yahoo or Facebook or Twitter, not what the…
Twister is interesting.  It's a decentralized "microblogging" system based on putting together existing protocols:  Bitcoin, distributed hash tables, and Bittorrent.  The most interesting part for me is using Bitcoin for user registration and spam control.  Federated systems handle this with federated trust, which is at least conceptually simple.  The Twister/Bitcoin mechanism looks intriguing though I don't know enough about Bitcoin to really comment.  Need to read further.