The Mythical “Private Office”

Several years ago I read an interesting book dealing with, among other things, developers productivity: based on research done at  IBM’s Santa Teresa facility, the author suggested that the productivity of developers can be substantially higher than industry average provided that they have private offices. Apparently, if you allow developers to work in an environment which does not provide any distractions, they are able to crank more code. Fair enough. I have to admit here that I read the text several years ago, so I might have gotten some names wrong here, but the idea stuck with me (and some other people as well) for a long time: the private office was the holy grail of software development.

I see and hear similar ideas surfacing from time to time and what amazes me nowadays is the fact that people still believe that number of lines of code (commonly used measure of developers productivity) is indeed a valid metric. If so, how come we’re all not paid by the number of lines we produce each month?

People pay us to develop software, hoping that they will get more out of it when it is up and running. When evaluating software projects they are interested in the value the product can provide to their business, not in the lines of code cranked in order to produce it. And this leads to an interesting conclusion: the amount of code anyone writes per month is completely irrelevant, it’s the value they provide that matters.

In contrast to “private office” camp, one of the fundamental aspects of Agile development is co-location of team members: the team should occupy the same office space. I have to admit that initially I was a bit skeptical, wondering why are the prophets of Agile so insistent on entire teams (not only devs) working so close together. But if you were lucky enough to work on a properly run agile project, you must have witnessed first hand the continuous buzz of conversation between team members: people will bounce ideas of each other, testers will harass developers and vice versa, pairs will discuss or argue approaches to solving problems etc. Some will say that this is not the most productive environment, and surely it’s not, but only if  measure productivity by the amount of code cranked per man-month.

The “conversation-bus” allows team members to publish/subscribe on demand so they can “plug” themselves into any conversation at any time in order to either add something of value or get something out of it. This has two major effects: first of all it promotes knowledge sharing and secondly (and more importantly) it allows pretty much anyone to contribute and add “value”. If you ask me, this is far more important than time lost writing code as out of those tiny conversation a better solution will invariably emerge. So keep the conversation-bus up and running and for those rare moments when you want to be all on your own get yourself a pair of headphones.

On the other hand if you ever hear someone on your team saying  “oh no, this is not the way you do it, why didn’t you ask?”, or people generally complaining about “communication”, read between the lines: they are not complaining about communication, they are complaining that they were not involved in the decision making process and no amount of meetings, emails, approvals, committees, steering groups or similar “remedies” is going to change it. Deprive people of ability to contribute, lock them in cells (or private offices) and the net effect is sinking team morale as there is nothing more frustrating than seeing your teammates trying to reinvent the wheel and invariably ending up with a square. Trust me, I have seen it way too many times, very often through the window of my virtual “private office”.

September 9 2010
blog comments powered by Disqus