[crazygringo]

I couldn't agree more. There is absolutely NO way to effectively measure programmer productivity.

If there actually were an objetive way, then it would be a different story. But in the absence of it, a team has to "look" productive at least, and that means people in the office looking like they're working. Even if it means less real work getting done (because again, how do you measure that objetively? can't be done).

[viscanti]

> There is absolutely NO way to effectively measure programmer productivity.

One of the big reasons programmer productivity is so difficult to measure, is that you need to also see future productivity of everyone else who works on the code. If a programmer takes an extra week to build something more maintainable and that improved design saves months of future work, it's likely a productive use of time, but that's not always obvious until those months are saved (or not saved). That's not easily measured until the full lifecycle of the software is complete.

[johnjlocke]

Measuring programmer productivity, as in long-term impact, is much harder than measuring how many hours Programmer X sits at their desk or how many lines of code they can spit out in a day. Those are metrics that other programmers notice after maintaining code that previous programmers leave behind. It's always going to be a delayed reaction.

[anuy]

i agree that working with breaks and socializing with colleagues for a coffee/a walk/ a fresh breath of air is good for productivity. however i do not agree with some posters who say that there are no metrics to measure productivity. there are ways to measure programmer productivity. not talking about lines added or features added. in general we can get a sense of how involved is a feature addition by looking at the list of data structures needed, algorithms to process the data, algorithms to list/display the output. more formal methods--http://secse08.cs.ua.edu/Papers/Danis.pdf

[prodigal_erik]

That approach can set a sort of lower bound on how much work a feature requires, but judging productivity also involves measuring how often the program fails to meet its specification and how much work to modify it could have been avoided up front.