[captaink]

I would say the best way is by the outcomes, by the results. By productivity - be it units produced, share price, value added...

Productivity is not = hours worked.

[ido]

Yeah but that gets pretty vague pretty fast.

How do you measure a programmer's productivity when you can't estimate exactly (and sometimes not even close) how much work something should take?

[neeleshs]

I have not seen a software project where there is not enough work for somebody.

What I've found useful, and which worked reasonably well for teams which have been working over a period of time together is to collectively estimate complexity of tasks that must be completed.Say on a scale of 1-5. That gives you a reasonably agreeable scale of measurement (not a universal scale, but the one that the team accepts). As time progresses, you see how many such tasks are completed by any person in a given time frame.

Not that this is foolproof, or that it works right from the beginning of a project, but over a period of time, you tend to get a good sense of how productive each member is.

[Edit: Typo fixed]

[ido]

Sounds pretty decent, although there is still the problem that it doesn't tell you if someone is slacking off or is simply not very fast.

[VBprogrammer]

Nor does it tell you anything about the quality of the work produced. Sometimes a job half done is worse than a job never started!