Slashdot Mirror
Best Seating Arrangement For a Team of Developers?
TekNullOG writes "I was given the job to prepare the logistics involved with moving our office. At the same time my bosses asked me to look into buying new desks for a small team of four developers and to consider if it could benefit the team to sit at a round table. In many offices and departments it increases productivity and makes collaboration easy. However, I am concerned that putting developers around a table could potentially be distracting consequently diminishing productivity by increasing coding errors. What are your thoughts?"
There are scientific studies that show significantly increased productivity by giving each developer their own office with a door they can close. Interruptions and distractions can torpedo productivity. These are mentioned, for example, in Steve McConnell's book, Rapid Development.
The agile crowd claims that having all the developers together increases productivity because you might overhear a conversation and be able to contribute something of use. In support of this they cite only personal impressions and anecdotal evidence. I know of not a single scientific study that supports their claim.
Yes the fad are Agile teams that all sit next to one another... but people tend to forget you will be down 1 FTE regularly because you all sneeze and cough on each other. Sickness runs rampant in those rooms... particularly if you have someone who is not hygienic in the group.
I am a developer, and I work under these exact conditions. We have two banks of desks grouped together in the middle of a open room. It is very conducive to collaboration, and it can get noisy when people get going. There is some group goofing off that occurs, but no more so than any other work arrangement I have seen. Most of us have some headphones, and so getting some quiet to focus inst really a problem.
HA! I just wasted some of your bandwidth with a frivolous sig!
I don't know, it may not be something they're immediately aware of.
A seating arrangement I've found works well is on the inside of a ring.
Have the desks setup with dividers so if someone needs to buckle down
and focus, they can, but if they need to confer, they can turn around.
I've tried cubes, offices, labs, and that setup, and I'd have to say,
for small groups, it seems to work out the nicest.
I wouldn't consider the mad hatter mad. Just reality impaired. He sure can make a mean cup of tea.
I've been in all sorts of offices. I actually prefer sharing a larger room over having my own tiny one or a cubicle, but of course there shouldn't bee too many peopl or there will just be constant chatter. So given that, a medium room with a handfull of pepople, I strongly dislike having my desk face a wall and my back to the room - it has only disadvantages. Mostly it's unnerving to have people moving around behind you. On the other hand facing the room has only advantages for me - it's more social, no one sneaks up on you and at least personally I'm not the least distracted by seeing things move around. It's the sounds that may be bothersome, but seeing what makes the sounds actually ameliorates the issue a bit.
There is a happy medium: http://www.joelonsoftware.com/items/2008/12/29.html Part office, but not all the way.
Don't click here...
Having gone through many office arrangement fads in the last 15 years, the one thing that consistently works, when management is good, is pretty much standard cubes or offices.
Collaboration without thought is simply placing people next to each other. Collaboration that is well thought out, is a good design process, good tools, and consistent clear management directives.
Another thing I've found useful is to not be stingy with tools (computers, software, extra monitors, etc...) and allowing people to have multiple of whatever they want. Let programmers have their own space or office (office is ideal), with 2 computers in each. If a couple folks want to team up for an afternoon, they can work in the same office. But come the next day, when they need to go back and focus on individual areas, zero distraction is what works. Computers are cheap in comparison to the salaries you're paying.
And lastly, the rest factor. If someone hits a wall, and just wants to zone out for 10 minutes browsing, say, slashdot:) for a while, doing so guilt-free because others can't see them is very beneficial. If instead there is pressure to work constantly, the quality of the work is going to go downhill. It has been estimated in various studies that people only do real work 5-6 hours out of an 8 hour shift.
That occurs for various reasons. But if people are pressured/forced to work longer than that national average, you'll still end up with people only working 5-6 hours out of an 8 hour shift, wasting 2-3 hours interrupting other people or zoning out pretending to work. And zoning out on nothing is boring, and de-stimulates the mind, making getting back into work slower/harder. If instead, a person is allowed to 'zone out' on something engaging (youtube video, phone call to friend, etc..) their mind will both be rested and still turned on when they return to work.
The last gig I did, I sat opposite the other developer who I needed frequent contact with. Everyone else got me by email, and I would initiate return phone calls. This avoided unnecessary interruptions in my workflow, and I could queue their requests to allow me to optimize my time.
In the past I've used similar setups. Do all the developers need almost constant face time with each other? Probably not. Then why stuff them in the same room?
At one company, everyone in the same office suite had their own office. That was maybe 1/3 of the development and systems staff. The rest were around the world. Communications were generally by email, except when live interaction was required. This kind of setup worked very well for me, so I could be at home, the office, or the datacenter, and there was no interruption to my workflow, except when I was traveling. It all worked out very well. It didn't matter what timezone someone was sitting in, the communications flow worked fluidly. That was a situation where all of the members of the crew were very good at their tasks, and didn't have to ask for help for stuff very much. Communications were limited to status updates and functionality interaction statements. Well, we'd BS sometimes, which was good for morale and to get to know each other better. I worked with a developer in Russia for probably two years before I ever heard his voice, and never did see him in person. I did know his work was accomplished properly, and his requests to me were usually "I need this functionality on these servers." I may ask for clarification, but since he knew what he was talking about his request were usually very clear.
I guess if you have a team who are going to have lots of questions because they aren't totally clear on what they're doing, stuffing them all in a room is a good idea. A well thought out and documented project plan would alleviate a lot of those problems though. I can imagine a room with 10 developers who can shout questions to each other would create an amazingly high amount of unwanted distractions. Verbal communications also reduce the paper trail. If everything is done via email, no one can say "I asked you for ..." and it wasn't done because it hadn't actually been asked for. The simple "You requested X at 3:30 and I responded it was completed at 5:00" is amazingly useful down the line. It completely eliminates mistakes in memory where we thought something was asked.
I've annoyed a few people before where I've told them to always email the requests to me. When they've failed to do so, but insist that they did ask for it, I can usually recite the conversation verbatim, and then they'll remember that they had only intended to ask for it, and never actually said to do it. That's usually enough to initiate the email papertrail so the same mistake doesn't happen again.
Serious? Seriousness is well above my pay grade.