a guy in a room


What's behind that door?
There? That's the office of my star programmer. We can't go in there right now though, I'll have to introduce you later.
Oh? Is he not there?
What? No, he's there alright, but he's been really busy working on an extremely important new feature.

The happy manager might make a joke or two and describe how he likes to slip a pizza under the door every now and then to make sure his star programmer is still eating. Some team members might remark on the fact that they haven't seen their coworker outside his office in a while. It's all good though. The problem is pretty hard and that's why their star programmer gets to focus on it. Just give him time, leave him room and he always delivers.

This makes me nervous.

Jim McCarthy warned about this in his book Dynamics of Software Development: Beware of a guy in a room.

I have encountered some variation of the guy in a room situation several times in the last couple of years. This is a sneaky issue, because it does not necessarily have to result in a problem. It obviously makes sense that the most competent person gets to work on the hardest problems. What happens though, if he or she simply can't solve it? With expectations heavy on his shoulders he might have his ego invested strongly in his work.

This may be a disaster in the making.

It can be a tough situation to deal with. Of course we want to have confidence in everyone. Of course we do not want to pester people with our questions all the time. Still, I don't think it's fair to make the team rely on one or two superstars. Ideally, everyone should be kept in the loop and be able to contribute somehow, where applicable. It's probably mostly the manager's job to make sure he or she understands how things are progressing - without necessarily interfering with it.

I am sure there are counterexamples and I would love to hear about and discuss them. In startups for example we very often end up with only very few people, so one person may well end up being responsible for all development. Other small teams may consist of a group of people who are each specializing in a different area. Or maybe you do have an industry legend on your team and this particular person simply never goes wrong. Does it make sense to accept the guy in a room situation in that case? Maybe even happily joke about it?

The danger I see in this...

Is when Star Programmer leaves the company... if only on person developmed most of the system, it will be hard for the remaining to pick up where he left off. You can only hope Star Programmer left behind good documentation :) But we ALL do that, right? :)

just as dangerous ...

... is when you trust your star programmer to deliver and confidently wait ... and wait ... and wait ... and for whatever reason nothing happens!

I worked with a guy who

I worked with a guy who referred to this as "The Mack Truck Problem". What happens if there's something that only one person knows about and they get hit by a mack truck? You're up the creek without a paddle until someone picks up the pieces and figures everything out. Does good documentation solve the problem? Maybe, but only if there's peer review of it before the mack truck comes along.

agree

As a fan of the agile methodology, I think that a "guy in a room" is a bad idea since it assumes that everyone knows weeks in advance what software should be built. In practice, there is a fine line between giving a developer space and time to dig into the problem and getting involved.

Weeks in advance? Try

Weeks in advance? Try months...
And our 'guy in a room' isn't even in the same building as the rest of us. He telecommutes from 150 miles away. And he wasn't assigned to work on the rebuild of our core product, the one he knows inside and out, the one he's maintained for the last four years.

Arrgh.

Three Years

hahaha.... we have one 5 hours away. Nobody's seen him in 3 years.

oh yeah ...

I am a big fan of PeopleWare and believe me, I totally agree that people need to have good working conditions, which basically means an environment in which they can be most productive. I am most productive in a quiet office that I have for myself. DeMarco, I believe showed evidence of a quiet office being a support for highly increased productivity almost 20 years ago already. It's unfortunate that a lot of companies still don't pick up on it.

However, this does not mean that people should disappear in the office and only sort of resurface when they want to enlighten the rest of the team with their achievements of the past week (month, year, ...)

that's exactly it!

Thanks for this great one, Cubicle Coder (or should I say Jay?), btw you've got an interesting blog too. At my first company after college there was a consultant there who had written a lot of the hard core stuff. He was a bit strange, and he was there for about a year or so after I came, but my last memory of him was when the CEO and CTO of this small ~25 person company were trying to pin him down on an issue. They wanted to know the relationship between Motif and X-Windows in layman's terms because of a certain problem that had happened with a client. I remember it clearly because they started shouting, and for an hour they got nowhere, and he had made the answer so convoluted that they could never put a finger on it. As a techie myself I found him to be very evasive. He was gone a few months after that.