The Futility of Developer Productivity Metrics
Linked by snydeq on Thu 17th Nov 2011 22:47 UTC
General Development Fatal Exception's Neil McAllister discusses why code analysis and similar metrics provide little insight into what really makes an effective software development team, in the wake of a new scorecard system employed at IBM. "Code metrics are fine if all you care about is raw code production. But what happens to all that code once it's written? Do you just ship it and move on? Hardly - in fact, many developers spend far more of their time maintaining code than adding to it. Do your metrics take into account time spent refactoring or documenting existing code? Is it even possible to devise metrics for these activities?" McAllister writes, "Are developers who take time to train and mentor other teams about the latest code changes considered less productive than ones who stay heads-down at their desks and never reach out to their peers? How about teams that take time at the beginning of a project to coordinate with other teams for code reuse, versus those who charge ahead blindly? Can any automated tool measure these kinds of best practices?"
E-mail Print r 0   21 Comment(s) http://osne.ws/jjz
Thread beginning with comment 497590
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: obsession with data
by looncraz on Fri 18th Nov 2011 03:15 UTC in reply to "obsession with data"
looncraz
Member since:
2005-07-24

Ultimately, any complex task is going to be impossible to measure via any cheap means or expert opinion. Ultimately, you'll have better luck with peer review, professional programs...

Amen!

I worked at a Fortune 500 company for a while and they forced you to use THEIR internal troubleshooting system regardless of whether or not you already knew how to solve the issue. You were FIRED if you didn't use the system.

I had 100% success rate, 15% troubleshooting guide use rate (they called it something else...), and came highly recommended from my peers and managers while also having received praise from most all clients.

None of that mattered, though... I was still penalized rather heavily on the 'scoreboard' and fell below the 'target performance' metric. I worked there a total of three weeks - I have the luxury of no mouths to feed but my own, I have no intentions of placating idiots with big fancy pieces of paper from big fancy buildings when I know more than they'll ever know...

[ Yes, I was fired ;-) - first time for everything! ]

--The loon

Reply Parent Score: 2

RE[2]: obsession with data
by Slambert666 on Fri 18th Nov 2011 08:05 in reply to "RE: obsession with data"
Slambert666 Member since:
2008-10-30

Probably not fired for "not using the system" but probably for being difficult to manage (as in making the managers job difficult).
Many companies tends to frown upon that, just so you know....

Reply Parent Score: 2

RE[3]: obsession with data
by senshikaze on Fri 18th Nov 2011 17:23 in reply to "RE[2]: obsession with data"
senshikaze Member since:
2011-03-08

While you are absolutely right, I would rather not fall in line and go along with the rest of the people in the cubicle farm.
Make waves, all the interesting people do.

Reply Parent Score: 1

RE[3]: obsession with data
by looncraz on Sat 19th Nov 2011 01:32 in reply to "RE[2]: obsession with data"
looncraz Member since:
2005-07-24

Probably not fired for "not using the system" but probably for being difficult to manage (as in making the managers job difficult).
Many companies tends to frown upon that, just so you know....


Yes, I was fired for a combination of reasons - they were listed (verbally):

1. Failing to use required tools
2. Management didn't like you because you didn't use the required tools and they couldn't monitor you
3. Complaining that the workflow required 3 monitors
4. Complaining about Internet Explorer 6's slow performance and lack of tabs


In the end, though, only ONE manager did any complaining (I had six... and was, myself, a 2nd level manager...LOL!) - and only because I was deemed a threat to his might. Co-workers complained and he was relocated and I was -eventually- offered my job back, which I didn't take.

Always more to the story ;-)

--The loon

Reply Parent Score: 2

RE[2]: obsession with data
by Alfman on Fri 18th Nov 2011 18:57 in reply to "RE: obsession with data"
Alfman Member since:
2011-01-28

looncraz,

Yep, instead of recognizing your good work, some bean counter had to justify their job by firing you even if it hurt the origination as a whole.

I too have been fired, but it was for the incompetence of another full time developer who found it beneficial to point the finger at me as a scape goat to the management. They paid me less than half of what they owed. That small company is no longer in existence.

I agree with Yamin that developers can usually recognize each other's strengths and weaknesses, but we also live in a time when politics are needed to get ahead and stepping on each other is often better rewarded than hard work. I don't think there is any possible combination of metrics that would fix this.

Reply Parent Score: 1

RE[3]: obsession with data
by Yamin on Fri 18th Nov 2011 21:27 in reply to "RE[2]: obsession with data"
Yamin Member since:
2006-01-10

I'd just add for emphasis, developers should not just be 'analyzed' by other developers, but by all people in the organization. Testers, product managers, customer support, sales, other groups...

Working in a large organization is complex and hard work or talented work is not all that matters.

Reply Parent Score: 3