How do you know the value of a programmer? 22:25 on Sunday

Three components to find the value of a programmer:

  1. Estimation accuracy
  2. Velocity
  3. Quality of output
Donkeys Three (Tres burros)
Donkeys Three (Tres burros), originally uploaded by .

The first is the ability to estimate tasks accurately. By following how well the estimates of a programmer have held with actual time spent on tasks, you can determine a variance value. You can use the maximum variance (representing the worst estimates of a given programmer), an average variance, or something in between. Pick something that feels statistically significant to you. Check FogBugz’ Evidence-Based Scheduling for a good take on this.

Estimation accuracy tells much more than just about good time management. You can’t really make good estimates if you don’t know your tools. Nor can your estimates be constantly accurate, if you don’t have a grasp of the kinds of recurring problems you will encounter in programming projects.

Velocity is how much code the programmer can deliver in a given time (not really referring to velocity as it appears in agile terminology). I haven’t found any reliable ways for measuring or calculating this, but again, the more data you have of all of your programmers, the better idea of each programmers personal velocity you will have. While the speed at which a task is finished is concrete and measurable, you can’t really value the velocity without comparision. If something gets done in two weeks and nobody in the world has done it before, was that fast or slow?

Quality of output is the fuzziest of these three criteria. My unproven idea is that the best judges for the quality of code are the programmer’s peers, other programmers. The quality of code can be valued better when you have laid down some guidelines for the programmers to follow. These could be adhering to common coding style (use of spaces in code, newlines, parentheses, use of underscores, that kind of stuff), or keeping the code readable (meaningful member names, informative comments). It could also relate to more technical quality issues like good memory management, or on the other hand, not bloating the code with memory management routines when it’s irrelevant. There are numerous criteria that can be devised.

Comments are closed.