The cost of Programmer Team Clustering
- by MarkPearl
I recently was involved in a conversation about the productivity of programmers and the seemingly wide range in abilities that different programmers have in this industry. Some of the comments made were reiterated a few days later when I came across a chapter in Code Complete (v2) where it says "In programming specifically, many studies have shown order-of-magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of programmers". In line with this is another comment presented by Code Complete when discussing teams - "Good programmers tend to cluster, as do bad programmers". This is something I can personally relate to. I have come across some really good and bad programmers and 99% of the time it turns out the team they work in is the same - really good or really bad. When I have found a mismatch, it hasn't stayed that way for long - the person has moved on, or the team has ejected the individual. Keeping this in mind I would like to comment on the risks an organization faces when forcing teams to remain together regardless of the mix. When you have the situation where someone is not willing to be part of the team but still wants to get a pay check at the end of each month, it presents some interesting challenges and hard decisions to make. First of all, when this occurs you need to give them an opportunity to change - for someone to change, they need to know what the problem is and what is expected. It is unreasonable to expect someone to change but have not indicated what they need to change and the consequences of not changing. If after a reasonable time of an individual being aware of the problem and not making an effort to improve you need to do two things... Follow through with the consequences of not changing. Consider the impact that this behaviour will have on the rest of the team. What is the cost of not following through with the consequences? If there is no follow through, it is often an indication to the individual that they can continue their behaviour. Why should they change if you don't care enough to keep your end of the agreement? In many ways I think it is very similar to the "Broken Windows" principles – if you allow the windows to break and don’t fix them, more will get broken. What is the cost of keeping them on? When keeping a disruptive influence in a team you risk loosing the good in the team. As Code Complete says, good and bad programmers tend to cluster - they have a tendency to keep this balance - if you are not going to help keep the balance they will. The cost of not removing a disruptive influence is that the good in the team will eventually help you maintain the clustering themselves by leaving.
