I now think that choosing roman numerals to represent parts in my series of posts about agile was a bad idea. It is not very scalable! This post, while related to agile, is not part of the series anyways.
A few months ago, I read blog posting about agile development. I think it was called 10 points to consider to make a good agile team. (Unfortunately I couldn’t find the article again.) One of the first few points was – I am paraphrasing – “Recruit best programmers/developers to the team..” When I was reading it, I thought, what sort of advice is that!
If you can get excellent, top notch, superstar developers in your team, then it is not a big deal to be productive. But, it is obviously not practical as a general practice. To start with, the terms excellent, top notch, brilliant etc. are quite vague. Even if you are experienced enough to figure out what it means and are able to determine if a candidate matches these vague criteria, not every software team in every company be able to find them. As a rule, if a developer is considered to be excellent, she will be relatively expensive compared to the more average developer. If you are working in a large company, there will be severe competition to steal better developers by different teams and not all of them are going to get the people they prefer. Since superstars are in high demand, there is always the fear of losing them!
Today I was reading an excellent article by Laurent Bossavit of Institut Agile (in French) named Fact and Folklore in Software Engineering. The article is about the oft quoted statement that “best programmers are 10 times better than the worst”. While I have heard this statement in my early days, I have never thought about it in depth and considered it to be an insignificant observation in practical software production. Bossavit goes into the history and evolution of this statement in great depth.
What attracted me most was the rigor with which the article was written. It is an excellent review in the scientific sense. He starts from the first published record of this statement to a 1968 paper by H. Sackman et. al. While this paper describes an experimental study, it actually measures difference between debugging task. Bossavit then continues to investigate further papers that repeats this claim either by referring to the original study or by referring to other studies that supposedly replicates this result. He then looks at a 2008 blog post by Steve McConnell which talks about this problem and does a survey of papers that apparently supported this claim published after 1968. The fun is when he tries to verify the references, which are either just repetitions, circular references or just opinion pieces. (I am not going to repeat this part. Read the post).
A common problem in software development is the subjectivity of measurement. There are so many matrices and methodologies to measure developer productivity both for predicting and rewarding. But, most of them are quite arbitrary. It is one thing to introduce a measure with the express acknowledgement of its arbitrary nature, for e.g Story Points used by many agile teams. But, when people start to take these numbers and then come up with complicated calculations of velocity and then plug it into traditional project management schemes, things start to crumble.
Another thin I noticed while reviewing the articles was that, they all measure the initial time to solve a certain task. In practical software development, the initial solution to a problem is just that. The total cost of that solution will not be clear until it goes in production and actual users start using it. So, just because a person can finish a solution to a problem faster than everybody else does not mean that she is the most productive.
I think the real challenge of a developer, especially a person in a lead/mentor role is to figure out how to achieve sustainable productivity with an average team comprised of average people. If you don’t have superstars in the team, you don’t have to fear losing those superstars!