A friend of mine has launched a blog that discusses the advantages and pitfalls of “wide teams” (distributed development teams).
Today’s guest blog addresses a number of those issues. Below is a response by me, on how many local development teams create many of the same problems and inhibit team development. Often with teams being nothing more than a group of individual players.
The Distributed Workplace – how many companies force the exact same model on their employees. Often in the name of “urgency and need”.
I worked for a number of good companies that have allowed “distributed workplaces” to appear in their local work groups.
Often employees work separately, and are not there to aid each other nor take advantage of each others different styles. They can be in the same office space just one cubicle over. But essentially spend most of the week working independently except for the occasional meeting.
Meetings seem to fall into two categories: the first is the periodic scheduled (ie: weekly morning meeting) which is focused on reviewing what people are working on, and how much progress is being made, and to discuss problems and delays that have reached a critical mass (ie: enough that non-IT management requires an update).
The second is the impromptu meeting. Which often arises due to an issue of delay or problem. In these meetings discussion often revolves around the problem and what can be done to help. Sometimes a few suggestions are made, a recommendation to try this or that. And then a return to ones desk. The result, said solution and ideas do not work and the project is bogged down. The programmer becomes discouraged. Often being held back on completing a task by one aspect (procedure, methodology, bug in the API/language, or an almost unnoticeable typo).
Often the problem could have been resolved much more quickly without a 45-90 minute meeting. But a sit down with 1 or 2 other developers.
In my own experience. I was beset by a problem. The problem wound up wasting near a week of time. I was told to utilize a certain language component; but it was not behaving as expected. When I couldn’t get it to work. I was told that I just didn’t have a good enough grasp of the component life cycle, and if I just took the time to understand it better than I would get it to work.
Days later I still have not made any progress. Now I was a week late on my task. Battling with a language component unsuccessfully. What I didn’t know was my co-worker had the same problem, and had to use a different component and method, because there was a issue/bug on the framework level.
The same thing I concluded “Something must be wrong with this component and how it functions in this situation.” Meanwhile, I wasted days trying to over-come a low-level problem when we had an in-house solution already present. The result – one discouraged programmer, now days behind.
Now, let’s not take away the fact that one can argue that I could have found the alternative, and probably should of. But at the time I felt boxed in. Being told this is what I should use and that I needed to make it work. Put me off from exploring alternative paths.
Had we merely had more interaction as a team and on a developer level I think the results could be very different.
I’d love to try a paired programming some day. As I believe I am a bad single programmer. You see, my brain works a little differently. I’ll often find solutions from a different angle than the norm, but likewise find myself bogged down on some syntactically complexity. Where as I know other developers who often excel at getting the code to work. But are not as intuitive on interface or creative implementations.
I believe that the programming world suffers, because programmers like me do not excel in it. We’ve lumped many aspects onto the programmer’s plates. Some of those are complimentary while others are in opposition. We want the programmer to communicate with the computer on computer terms and then turn around and communicate to the average office work on human terms. We expect a programmer to be able to deal with a multitude of rote syntax and critical debugging while at the same time we want them to excel at creativity and thinking outside the box.
These are tasks that are in direction opposition. And yet pairing two types of developers can, I believe, create a very powerful and dynamic team. With one programmer who excels at the syntax level with another who is more creative and/or thinks differently. The result is a team who can build a better mouse trap when working together.
The problem is the corporate thought. We need to get this done yesterday. We have two developers, so clearly the fastest way to get this done is to have both developers work on parts of the project – because 1 + 1 = 2. The result is each developer must suffer the delay of their own weakness with no one there to bounce ideas off of, to point out simple typos, or brainstorm when hit with a roadblock. The alternative is to put two developers on one task. I’d liken it to 2^2 = 4. The two developers can cover each others weaknesses as well as fuel each others strength. But this does not compute to a traditional business philosophy. Two workers working on the identical task equates to inefficiency to the minds of management. And few developer teams are willing to take the risk and expend the people energy to see the potential benefit of team development.