We have a theory, here, that this is a bad idea. Using timesheets as a performance metric can lead to only one thing: bad data in timesheets.You really need to read the whole post to understand where he is coming from, but I agree with his point. As soon as someone knows how you are measuring their performance, many people will find a way to "game" the system. What Joel doesn't do, likely because this was not the real point of his post, is mention how he measures developer performance. So the question is:
How do you measure performance for developers?I wish I had a good answer for this. I have always thought performance should be measured by what you accomplish, not how long it takes to accomplish it. If the task is to create three reports for the accounting department by the end of the week and one developer gets it done by Tuesday and surfs the net for the rest of the week and another developer gets it done on Friday, which one performed better? Both met the expectation, working under the assumption that the reports work the same, so how do you evaluate performance? Granted the one who finished sooner could be assigned more work so is more productive, but both met the requirement.
I had a short contract position writing SSRS reports for a company. The first day I showed up, they had a certain number of reports spec'd out for to work on and expected it to take me several days to get them done. Well, by the middle of the second day I had completed them all and the Business Analyst I was working with didn't have anything else ready for me and I was expected to be there from 8 to 4:30. I couldn't leave, but I wasn't being productive, yet my employer was happy with my perfomancem and my contract, which was originally for four weeks, was extended and I ended up there for six months.
The point of the story is that I had days where I was paid for 8 hours and worked 3-4 because I was waiting on someone else. So was my performance good, they thought so. Also my timesheet showed 8 hours worked, which really isn't accurate.
This also relates to the editorial at SQLServerCentral. Be sure to read the discussion as well.
Jack, it IS hard to measure stuff, and things that get measured often get gamed - but don't stop measuring! Better to measure a few things and learn than to measure nothing and hope for the best.
ReplyDeleteAndy,
ReplyDeleteI'm not suggesting not measuring, I'm wondering what to measure and/or how?
I had a computer science instructor in college who was an old C++ programmer. He said that he had an employer that measured performance by the number of semicolons (statement terminators) in your code, as if more statements means better code. So, the common modus operandi for his group was to add extraneous semicolons throughout the code. If there is an arbitrary measurement of productivity, it will eventually be hacked.
ReplyDeleteTim,
ReplyDeleteThat is a good one. Kind of like when you have to write a 500 word paper in the sixth grade and you use "and" and "very" a lot.
Again, the real question is how do you measure performance? It relates not to just developers, but other jobs as well.