Well, if your goal is comparing two programmers, then the most obvious thing to do is to give them both the same set of diverse tasks, and see how long they take (on each task and on the whole set).
If your goal is gauging the effectiveness of this or that approach (agile vs. waterfall? mandated code formatting style or no? single or pair programming? what compensation structure? etc.), then it’s slightly less trivial, but you can use some “fuzzy” metrics: for instance, classify “desired things” into categories (feature, bug fix, compatibility fix, etc.), and measure those per unit time.
As for disagreeing whether something is one desired thing or three — well, like I said, you categorize. But also, it really won’t be the case that one programmer says “I just implemented a feature”, and another goes “A feature?! You just moved one parenthesis!”, and a third goes “A feature?! You just wrote the entire application suite!”.
Well, if your goal is comparing two programmers, then the most obvious thing to do is to give them both the same set of diverse tasks, and see how long they take (on each task and on the whole set).
That might work in an academic setting, but doesn’t work in a real-life business setting where you’re not going to tie up two programmers (or two teams, more likely) reimplementing the same stuff just to satisfy your curiosity.
And of course programming is diverse enough to encompass a wide variety of needs and skillsets. Say, programmer A is great at writing small self-contained useful libraries, programmer B has the ability to refactor a mess of spaghetti code into something that’s clear and coherent, programmer C writes weird chunks of code that look strange but consume noticeably less resources, programmer D is a wizard at databases, programmer E is clueless about databases but really groks Windows GUI APIs, etc. etc. How are you going to compare their productivity?
That might work in an academic setting, but doesn’t work in a real-life business setting where you’re not going to tie up two programmers (or two teams, more likely) reimplementing the same stuff just to satisfy your curiosity.
Maybe that’s one reason to have colleges that hand out computer science degrees? ;)
And of course programming is diverse enough to encompass a wide variety of needs and skillsets. Say, programmer A is great at writing small self-contained useful libraries, programmer B has the ability to refactor a mess of spaghetti code into something that’s clear and coherent, programmer C writes weird chunks of code that look strange but consume noticeably less resources, programmer D is a wizard at databases, programmer E is clueless about databases but really groks Windows GUI APIs, etc. etc. How are you going to compare their productivity?
Very carefully.
In seriousness, the answer is that you wouldn’t compare them. Comparing programmer productivity across problem domains like you describe is rarely all that useful.
You really only care about comparing programmer productivity within a domain, as well as comparing the same programmers’ productivity across time.
I’m going to look at the total desirability of the what Adam does, at the total desirability of what Bob does...
And in the end I’m going to have to make difficult calls, like how desirable it is for us to have weird chunks of code that look strange by consume noticeably fewer resources.
Each of them is better at different things, so as a manager I need to take that into account; I wouldn’t use a carpenter to paint while the painter is doing framing, but I might set things up so that painter helps with the framing and the carpenter assists with the painting. I certainly wouldn’t spend a lot of time optimizing to hire only carpenters and tell them to build the entire house.
Well, if your goal is comparing two programmers, then the most obvious thing to do is to give them both the same set of diverse tasks, and see how long they take (on each task and on the whole set).
If your goal is gauging the effectiveness of this or that approach (agile vs. waterfall? mandated code formatting style or no? single or pair programming? what compensation structure? etc.), then it’s slightly less trivial, but you can use some “fuzzy” metrics: for instance, classify “desired things” into categories (feature, bug fix, compatibility fix, etc.), and measure those per unit time.
As for disagreeing whether something is one desired thing or three — well, like I said, you categorize. But also, it really won’t be the case that one programmer says “I just implemented a feature”, and another goes “A feature?! You just moved one parenthesis!”, and a third goes “A feature?! You just wrote the entire application suite!”.
That might work in an academic setting, but doesn’t work in a real-life business setting where you’re not going to tie up two programmers (or two teams, more likely) reimplementing the same stuff just to satisfy your curiosity.
And of course programming is diverse enough to encompass a wide variety of needs and skillsets. Say, programmer A is great at writing small self-contained useful libraries, programmer B has the ability to refactor a mess of spaghetti code into something that’s clear and coherent, programmer C writes weird chunks of code that look strange but consume noticeably less resources, programmer D is a wizard at databases, programmer E is clueless about databases but really groks Windows GUI APIs, etc. etc. How are you going to compare their productivity?
Maybe that’s one reason to have colleges that hand out computer science degrees? ;)
Very carefully.
In seriousness, the answer is that you wouldn’t compare them. Comparing programmer productivity across problem domains like you describe is rarely all that useful.
You really only care about comparing programmer productivity within a domain, as well as comparing the same programmers’ productivity across time.
I’m going to look at the total desirability of the what Adam does, at the total desirability of what Bob does...
And in the end I’m going to have to make difficult calls, like how desirable it is for us to have weird chunks of code that look strange by consume noticeably fewer resources.
Each of them is better at different things, so as a manager I need to take that into account; I wouldn’t use a carpenter to paint while the painter is doing framing, but I might set things up so that painter helps with the framing and the carpenter assists with the painting. I certainly wouldn’t spend a lot of time optimizing to hire only carpenters and tell them to build the entire house.