[nadam]

You can quite well measure productivity if you set a task, write tests for it, and tell two independent groups to implement it. You give them the same amount of time.

Now the more productive / better group is which can do the task with smaller complexity.

Complexity measures measure size of code and number of dependencies between blocks in different ways. But even the most simple comlexity measure is quite good: just measure number of tokens in source code. (It is a bitmore sophisticated than LOC). You can then make competitons between groups, and measure their productivity. (I am writing a book now titled 'Structure of Software' which discusses what is good software structure on a very generic/abstract level. It relates to 'Design Patterns' as abstract algebra relates to algebra.)

[alok-g]

Genuinely asking: Why not just stop at "tell two independent groups to implement it"? That is, why constrain to the same amount of time?

[nadam]

Because we measure the quality of their output. A weaker group can solve the problem with the same quality as a stronger group given much more time. (For example by doing refactoring in the plus time.)

[alok-g]

I see. The time constraint you set is on the tighter side. I was considering it to be on the relaxed side which would allow the weaker group to improve as you said.

On the other hand, setting the time constraint (as opposed to measuring both time taken and solution complexity for the two groups) is important because deadlines help.