2002/04/30

Today at lunch I finally got a chance to do something I've been waiting for ten years to do: I sat down with Tom DeMarco to talk about office space. I've been a strong believer in private offices for developers, something which Tom advocates in his bestseller Peopleware. I asked him about how pair programming can be reconciled with private offices; I imagined that a buzzing room full of developers working in pairs would be too distracting an environment to get into flow and stay there. Tom said that groups of people who work in the same style on the same kinds of tasks will not distract each other. Programmers working on the same project would not distract each other; a room full of sales reps who spend most of the day on the phone don't distract each other; etc. You get in trouble, though, when you put a programmer in a room with the sales reps. We generally agreed that if you keep the noise level down and keep the outside interruptions away, it's OK to have an open space floorplan for your development team.

That said, if you're doing pair programming, you're not going to spend more than 3-4 hours a day working with your code buddy. For all the other things you do (phone conversations, design discussions at the whiteboard, etc.) it's nice to have private offices. And when you're trying to recruit superstar programmers they will expect a plush private office. (Just try and get Tom Cruise to make your movie if he doesn't get his own dressing room.) So now I'm envisioning the ideal development interior plan as one where programmers have private offices but they meet in labs with their buddies to get production programming done. No email, phones, or non-programmers would be allowed in the labs. All the non-programming work you do -- design, negotiation, scheduling, reading, thinking, and Tetris -- could be done in your private office.

World's Worst Misinterpretation of The Mythical Man Month

When I read this article by Scott Rosenberg for Salon, I thought it was a complete misapplication of the Mythical Man Month. Reviewing a large body of existing code to find security problems is easily divided up among huge teams of people, and should not suffer from any of the Mythical Man Month problems. The article is just flat-out wrong. The nice thing about being at the Cutter Summit is that I can ask Mark Seiden, one of the world's foremost experts on computer security, if I'm crazy. "You're right," he said, "it doesn't apply. There are no interdependencies to speak of."

My new book is here! Apress has just published a new collection of 36 essays from Joel on Software, aptly named More Joel on Software. Get yours today! Available from Amazon.com or wherever fine cheese is sold.

About the Author: I’m your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz—the smart bug tracking software with the stupid name, and Fog Creek Copilot—the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.