Software development and private offices

Matt Blodgett recently twittered about developers and private offices.  “I wonder if mgmt knows how bad they are killing productivity by doing that? Are they ignorant, or just stupid?” was a followup twitter I got from him, and I started replying.  Twitter’s too limiting for what I was trying to say, so I’ll say it here.

My experience has been that “management”, in the general sense, sees software developers as interchangeable parts. And many are.  I’ve been at some places where the development part ‘is just a job’ to people.  They go home to their kids/families/whatever, then come to work the next day.  They don’t get all that excited/interested/passionate about the technology @ work – they just ‘work’.  This is not talking bad about these types of developers – they’re necessary, and a good thing to have in moderation at companies.  “Sure and steady” is how I describe many of these people.

But there’s also the ones who get passionate/excited about new tech and new ideas and new techniques.  I’m that way, and chances are you are too, if you’re reading this.  You’re reading a blog (or feed) which is still relatively ‘cutting edge’ technology among the ‘sure and steady’ dev crowd.  Again, just talking about my experiences with people, but I’m going to guess many of you know what I’m talking about.

With either type of developer, public open work areas prove to be distracting.  People walk by, discussions start, and other things happen to interrupt the concentration.  You lose “the zone” you were in, and it takes a long time to get back in there, if you even can that day.  Quantifying that productivity is very hard, especially to immediate management.  Usually their entire day is made up of interruptions – putting out fires, meetings with others, etc. so often there’s not a lot of sympathy, unless your managers were once developers.  That transition often isn’t successful either, which is why you don’t see too many developer->manager types.

I’ve seen one work area recently where the owner of the company was out in the ‘bull pen’ area with all the workers, but it was not a development shop.  Still it was inspiring to see that sort of commitment from an owner, being there in the day to day hubbub of activity.  This company also is a moderate rising star in the area, so perhaps those 2 facts are related?  :)

In open work areas you’ll often see developers trying to ‘get in the zone’ by wearing headphones.  I’ve even been told before that I should just ‘wear headphones’ to block out the office noise. This was said to me by someone who then walked back in to his private office closed his door. (heh)  Most music distracts me, but beyond that, music/sound/headphones only blocks out certain frequencies, and still doesn’t stop visual distractions of people walking by.

The ideal dev area, in my mind, would be a combination of the following features. I’ve heard of these places, but have only seen one in person, and it still didn’t have all of these characteristics.

  • Small private one person offices with doors for dev work
  • Small offices to hold 3-6 people for group meetings, testing, etc.
  • Larger offices for team meetings (6-15 people – obviously depends on the team size!)
  • Large open area (or 2) for more open/casual discussion.

All areas shoud have wifi or appropriate connectivity for the number of people the space should accommodate.

Anything short of this is compromising the productivity of the developers.  It’s hard to quantify, but easy to see the positive results of productive developers.  With an environment like the one above, the ones who need private space for the ‘heavy lifting’ get it, and the ones who need the public space for larger meetings get it, and the small groups get their spaces as needed too.  There’s something for everyone there.

Given the larger stake that software plays in companies these days, it’s sort of surprising that more companies don’t treat the developers better.  These are the people who make the company more efficient, whether through direct development, or integration between existing systems/packages.

All this isn’t to say ‘private offices’ will make the entire dev team x% more productive.  However, you will likely see an increase in productivity and/or code quality from a large number of devs on your team by implementing this sort of office setup.  And if you don’t, it’s one less excuse someone can pull on you before letting them go.  :)


I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati

{ 13 comments to read ... please submit one more! }

  1. Great post, Michael. You might find it interesting that while I was formulating a response to your post, I was distracted several times by the gentleman who sits next to me and talks to himself loudly all day long.

    I liked your point about managers not being able to relate to developers because constant distractions are part of their job description.

    I once made a list of some excellent quotations from one of Paul Graham’s essays where he discusses this topic. I’ll dig those up and include them in a blog post some time soon.

  2. Cool Matt – I’ll look out for it. I’m becoming more sensitive to sound and distractions as I get older, and even people chewing gum bugs the heck out of me. Back at the last company I was at, I know darn well the CFO wouldn’t put up with someone popping bubbles 4 feet from his ears. But somehow I’m supposed to? We both need mental concentration, but there’s only one of him, and there were 10 of us, so ultimately I left. Not specifically because of gum chewing, or even noise, but those certainly didn’t help. They ended up putting all the devs in cubes after I left, which just shifts the problem – still no door, no peace, no quiet, etc. Hrm…

  3. Great article, Michael! Very timely for me. My experience has taught me that the “open office” (pun not intended) is great if you have a team of developers working day in and day out on one project. One of my contracts back in the day was on staff aug on a product dev team. We all sat at one long card table to work, and for one month we got to use one of the large training rooms. These setups definitely helped productivity: big time.

    Fast forward to today: my current company has an open setup and a few offices for the most customer-facing individuals who are on the phone more than not. It’s not too bad to work in the open area most of the time, but I find that it doesn’t increase efficiency at all, since I’m rarely working on the same project as other co-workers. In fact, right now we’re in crunch mode, and I’m writing this from the desk of one of the offices, where I’m holed up in order to focus on development.

  4. That manager that walked backed into the private office wasn’t me was it? ;)

  5. No Dave, it wasn’t you. :)

  6. A number of thoughts prompted by this post:

    Re: “sure & steady/loner” vs. “passionate/interactive” developers: I think it’s important for software developers to strike a healthy balance between these two modes, and I agree that a private office is ideal for those times when you really need to focus, but many companies can’t afford them. A really good pair of noise-canceling headphones is almost as good though. They really do make a difference. I often wonder why companies don’t let employees work from home, where they can REALLY be productive (assuming they don’t have kids around during the day).

    The open office is designed to let management easily keep tabs on employees. It is clearly based on the concept of the “panopticon” (see http://en.wikipedia.org/wiki/Panopticon):

    “…a type of prison building designed by English philosopher Jeremy Bentham in 1785. The concept of the design is to allow an observer to observe (-opticon) all (pan-) prisoners without the prisoners being able to tell whether they are being watched, thereby conveying what one architect has called the ‘sentiment of an invisible omniscience.’”

    The open office makes it very easy for management to see what is on everyone’s monitor. I think companies often mistake “developer productivity” for meeting an arbitrary deadline with an arbitrary set of requirements, when most of the time in such situations, the resulting product doesn’t actually meet the needs of the end user, and the code is crap. Contrary to what most managers believe, developer conversation is good for REAL productivity, measured in quality of deliverables and customer satisfaction, which ultimately translate into profit and sustainability.

  7. Hey MPS – good points. ‘sentiment of an invisible omniscience’ – isn’t that what many religions are supposed to do as well? Funny you mention Bentham – I met a guy in the SFO customs line a few weeks ago who was a Bentham scholar. He’d just come back from the UK where he’d had direct access to a number of unpublished Bentham papers and he was writing a book on Bentham’s views on sex and sexuality. Look for it in a Borders near you next year!

    The work from home angle, if even on an ad-hoc basis, surely would be better for the times when a dev knows certain things need to get done and would be more productive @ home.

    Joe’s point above on the issue of working on the same project together was also a good one. Remember our time together, 6 people in one room, it was rare if 2 people were ever working on the same thing. Perhaps 2 sides of the same project, but ‘pairing’ was almost non-existent.

  8. Our open office has nothing to do with keeping tabs on developers. In fact, it has a lot more to do with having sufficient communication among developers. Anyone who’s read Peopleware knows that preventing interruptions, and giving people sufficient space are key metrics. However, in the time since then we’ve also learned how to leverage unit testing and pair programming to make software ever-evolving, releasable every few weeks, and achieved other major milestones. At the rate of development our teams move, having them all in an open office-style environment has been key to their communication, and ability to get things done. However, I’d like to get to a point where they have more opportunities to “hole up” in a room as necessary. Right now, we keep the corner office open for just this purpose, but the challenge comes in determining a good compromise between a laptop for everyone and having more screen space (like dual-monitors) while at the desk.

  9. Having seen what you have going, knowing that you still have ample meeting room space to accomodate the private meetings that become necessary, I’d say you have a decent balance. The challenge will come as you grow more in the coming year – growing the physical space vs changing how you use the existing space will be an interesting compromise.

  10. Excellent article Michael. I had achieved the private office for a while but am back in an open environment. It’s not all bad, but working around distractions is an art form. Discussions like this always remind me of my favorite Joel on Software article where he describes the offices he provides for his developers. He definitely gets it.

  11. What a terrible case of trying to force what works best for you on everyone else. Developers should be given whatever environment maximizes their output and quality. For some developers, that might be a private closed single. At my company, we let developers choose between private closed singles, private closed doubles, and open areas.

    A small number choose open areas. A good number choose private closed singles. Most choose private closed doubles.

  12. Excellent point, Shambolic. Freedom of choice is the key issue here. I realize open areas are often provided with good intentions, but they can still lead people to feel – albeit subconsiously – like they are being watched. A lot has to do with the physical orientation of the workstations. My last job was particularly bad in this respect. The desks were all positioned in a square with the monitors facing inward, and the manager’s office had a door, of course, but glass walls to enhance the lack of privacy. A minor re-arrangement of the desks is all it would have taken to fix that problem – something along the lines of the Joel on Software article mentioned by Paul R.

    Now don’t get me wrong – I am all too aware of the myriad distractions of the Internet for software developers these days. Give a person with a bit of ADD unfettered Internet access and a private office and you’re lucky to get any quality work out of them at all. Internet addiction is a very real issue, and some people really do need a little *less* privacy in order to stay focussed. Of course, such people probably shouldn’t be doing software engineering for a living. I’ve been in a situation of having to let an employee go because of his surf/work ratio.

    Anyway, good discussion y’all! :-) Keep ‘em coming.

  13. I was starting to reply to shambolic last night, but never finished it. Sham – who are you saying is pushing their one way on others?

    One other factor that I’ve picked up on – people point to the Joel Spolsky article on offices and such, and then compare that to their own. A big difference between that sort of development and what many of us do is audience. If you’re doing internal software development, you’re likely looked at as a cost, or the whole dept as a cost center. If you’re doing development on a product or service that will be delivered to paying customers, you’re not viewed as a cost center (or shouldn’t be, anyway). The way developers are treated re: privacy, office, oversight and, often, respect, often has a lot to do with the type of software you’re developing – internal systems vs external products. I know this is just one extra variable in the discussion and is a broad generalization, but has been my experience so far.

{ 0 Pingbacks/Trackbacks }

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">


Get updates on my upcoming book!
  • Get better clients!
  • Make more money!
  • Avoid costly mistakes!
I'm hard at work writing a book which will give you everything you need to know to get started in web freelancing, from getting clients and getting paid to contracts and what types of work you should consider.