Productivity

Reg Braithwraite wrote a bit of food for thought on productivity.

I think when people talk about productivity, they often set "high productivity" as goal to be achieved, when really, we can only measure the state of completion of individual tasks. Wrote a test unit. Check. Implemented form validation logic. Check. Designed wireframe. Check. Achieved high productivity. Huh? What does that even mean?

Notice how, despite being very measurable and sometimes even paramount to get a project out of the door, none of the tasks I mentioned can really be measurements of productivity:

• Write a test unit. Pretty important in TDD. Not what you should be working on when you're putting up a prototype demo that will be used in a sales presentation that you've just been informed will start in 2 hours.
• Implemented form validation. Anyone knows it's important, but rolling your own when the framework has a built-in function to handle the exact same case is sometimes a waste of time. The opposite can be true too: you might find that using a framework built-in helper to save 2 minutes wasn't worth the 2 hours you end up spending on it when the qa phase comes along and a bunch of cases are broken.

Etc. Etc.

If I don't know what your goals are, and you don't know mine and we have no idea what each other's teams can and can't do (because of knowledge levels, corporate constraints, programming languages, frameworks, workflows, whatever), how can we intelligently discuss productivity improvements? It strikes me as odd that people would go as far as preach a methodology or even a coding practice as "the one", when I think about it from this angle.

Besides, hasn't there been enough articles around the tubes saying how rewarding programmers based on their individual "performance" is a bad idea?

Why do we even talk about productivity?