Friday, September 29, 2006

Developer: Will work for room!

Jeffrey Palermo has a series post that talks about his view on How to Produce Software Quickly and while I agree with almost everything he says I did do a big double take when I saw his comments regarding slow communication.

Now I'll start with the caveat that I don't know what Jeffrey means when he talks about a team. Is he talking two people? five people? twenty people? Because these numbers all have different meaning when you talk about putting that many people in a single room. I've worked two people to a room.. I've worked six people to a room.. I've even worked twelve plus to a room and each was a unique experience.

Personally I am of two minds to this... the first part agreeing that team communication can be an important thing.. but this comes with a few caveats..

  1. The room itself has to be setup properly. There needs to be a few things put in place to manage noise and distractions as much as possible. There should be a door to the room that closes.. the room should be built in such a way to control noise (carpeting, dropped ceiling, etc).. and there should be a limit on having meetings in the room. If your entire team is going to be involved in a meeting and you want to have it in the room then great but if two out of six people are required then move it to another room.

  2. The more people you have in a room the more you are going to negatively affect productivity because the "problem" with people is that we all have our own quirks. People have various tolerances for noise and have various habits that generate noise. For instance I tap my foot a lot.. and according to various people I hit my keyboard keys ‘loudly’. I’m good at ignoring constant environmental sounds but any discussion occurring will immediately make me lose my train of thought and often times pull me in. Each person is unique in what they do and what level of distraction they can take and so even in a small group environment you are going to have people who are never able to enter the “zone” where they can code for two hours straight to solve a really complex problem without realizing that two hours has even passed.

  3. The more junior members a team contains the more valuable communication is going to be. In a team where most of the members are either junior or intermediate and they are being managed by one or more senior developers having that open environment where people can quickly bounce ideas and concepts off each other is going to be worth the loss in individual performance. The inverse of that is that the more senior members the team has the less benefit you get from an open environment. In this kind of situation you are going to want to affect individual performance as little as possible.

So now that we've gotten the group communication thing out of the way let's get down to my other point of view.

Noise and distraction suck.

The "zone" is real! Many of us have coded for hours straight on a complex problem and we look in shock at the time and realize how much time has really passed. Or as I like to call it the "Holy crap it's already time to go?" moment.

At a more senior level in my experiences it seems to me that communication usually comes down to a few forms.

  1. The "What the heck is this component suppose to do anyway?" question.
  2. Something you need from another developer to do your job.
  3. The best way to code a complex issue.

The first form of communication is obviously a very bad thing and should not be happening. It’s a sign that the proper procedures and/or project management are not in place. You should never have to ask someone else what this should be doing. You should be looking in Sharepoint (or whatever you use) and finding the business rules and requirements for that component. You should have a list of what your team wants to accomplish this week and you should be working off a priority based task list. Even if you're the one writing that priority based task list at least it exists so others can look at it and tell when/what is going to be available for testing (yes.. yes I love TDD too but you are backing that up with a little bit of Q&A aren't you?). If you find yourself constantly having to get up to ask questions about the code you are writing then that should be a big flashing red light.

The second form of communication is actually another sign of problems. Your co-developers should know what is required of them this week, and they should be emailing you a list of what they have done with instructions as to it's use. If you get to a point where you have to stop work and ask them for something you are already wasting valuable cycles. Sure you can task switch while they finish up whatever it is you need but it's much preferable to never have to task switch at all.

The third form of communication is actually very important to any level of developer. Any smart person knows that nobody knows everything. There is usually more then one way to solve an issue and by taking a few minutes to discuss a complex issue with another developer you may get the mental kick you need. But at the same time this form of communication should be rare, happening only when a developer is working on something that is difficult or unique in some way. If a developer requires feedback on every single thing they code then something is wrong. Either the component is too complex and needs to be broken out a bit better.. maybe splitting it up a bit OR there is a problem in problem solving skills that needs to be addressed. This form of communication is the reason a developers room has a white board and a few addition chairs in it.. so that on those occasions where someone does need to come over and discuss how a component should work a small group can get together to it discuss without interrupting the other members of the team.

So in the end I’ll update my developer per office concept to be..

  • A room per senior developer who is working independently.
  • A room shared per senior/intermediate developer and the developer she/he is mentoring.
  • A room shared per two to three team members who are working together on a project.

At least that's how I see it...