I have proposed the heresy that all programmers are not created equal. I further dissed most typical correllations to programmer productivity (title, salary, etc.) may not be useful in predicting differences in productivity. Thus I have turned to a different system.
I classify developers as Masters, Journeymen, or Apprentices. This is a taxonomy I picked up from Ken Auer of RoleModel Software; I think he got if from a former company he worked at, KSC. But I have seen other references in the literature to it as well. The model refers to craftsmen of the Middle Ages, but applies to many disciplines today that involve learning a skill.
Briefly, an apprentice is a developer who is still learning the requisite skills. Constant supervision is necessary because an apprentice may not know when she/he is doing something wrong. Techniques are being learned, but the why of the technique is still a bit vague. Stringing together techniques is a bit beyond the apprentice.
A journeyman has mastered the techniques of the craft. Supervision is rarely required. Given a task, journeymen can complete it in reasonable time with quality results. But they are not yet masters.
A master has all the journeyman skills, but also is able to innovate within the craft. Given a new problem, the master can conceive of a solution. Then the journeymen can be turned loose to help him implement it.
In an Agile team, the skill I am looking for is object-oriented programming (OOP) because Agile hinges upon the ability to write code that can change. Most programmers don't know how to do that, particularly with object-oriented programming. Don't confuse object-oriented programming with object-oriented languages like Java, C#, C++, or Ruby. Using one of those languages (sadly) does not ensure an understanding of object-oriented programming.
An apprentice in OOP is a effective programmer and can construct loops, methods, and classes, but is still learning how to separate the business problem into objects. Encapsulation is being learned (which means no getters or setters for the classes). Code is being placed into the appropriate classes rather in giant god class. if statements litter the code as the apprentice is still learning design patterns to eliminate them. Class sizes and method sizes tend to be larger than smaller. Code requires comments to aid in understanding, and blank lines are common in the middle of methods to group code together. An apprentice is beginning to understand the patterns of bad code (the imfamous code smells), but lacks the tools to understand how to eliminate them.
The journeyman is adept in OOP techniques. The classes exhibit crisp conceptualizations distinguishing them from each other. Boundaries are clear; methods are small. Design patterns are common, and exist in inverse proportion to the number of if statements. else statements are quite infrequent, and case statements have vanished. (I write about one case statement every 18 months or so.) Given a problem and a broad outline of a design, journeymen will implement it with little need for supervision or support.
A master has all the above skills, plus a near magical ability to hear a problem and see objects for a solution. They never seem stuck, and always seem to have a solution to the code smell that is stumping the journeyman. A quick conversation with a master can remove a barrier slowing down a journeyman, or reset the direction being taken to save significant effort.
So why bother with this classification? The corresponding productivity model, particularly on significant, business critical applications. Let's say a regular programmer produces at 1x. An apprentice is essentially a 1x programmer. Then a journeyman is a 2x programmer. There is that much difference in learning those OO techniques. But a master... Well a master is a 5x-10x programmer! They can literally run circles around an apprentice. Even more important, when an apprentice can't get anything done because of the complexity of the problem, the master cuts through it like a hot knife through butter.
A true example from a former client project: In the third release of a project, we reduced the team size to six programmers. These six programmers were keeping 17 acceptance testers hopping just to keep up! The client was running around the halls trying to find additional testers. The six programmers: four masters and two journeymen, a virtual team of around 40 in productivity. No wonder it took so many testers to keep up.
So in my resource planning spreadsheets, I literally identify apprentices, journeymen, and masters as separate resources, and use 1x, 2x, and 5x multipliers to get a virtual body count. I use the virtual body count to compare to non-OO waterfall estimates of the same work. And I never count a swap of a master for a journeyman.
More musings on the M-J-A model in later posts...