Slashdot Mirror
The Futility of Developer Productivity Metrics
snydeq writes "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?'"
Whatever you measure will be gamed. Measure bugs fixed, and you will find people wasting time listing each tiny variation of a bug. Measure lines of code, you will get spaghetti code.
It almost seems better to measure a bunch of things and use a secret formula to determine productivity.
Man, you really need that seminar!
A lot of problems rating developer productivity. First, if a system is that good, then managers won't be able to game it to play favorites. Second, writing code for future use is always harder than writing code specific to the problem. Third, almost any metric is going to penalize a simpler solution. (Keep in mind that once you see a simple solution it seems obvious and everyone thinks they'd think of it. Fourth, evaluating developers well would require making the best coders managers, and that rarely happens for several reasons.
Democracy Now! - your daily, uncensored, corporate-free
Can any automated tool measure these kinds of best practices?
No. The - for the sake of politeness, let's call them "people" - who invested time and effort into devising these schemes have actually built a complete chain of negative productivity by doing so. Remarkable.
OMG!!! Ponies!!!
metrics provide little insight
If only we had some kind of.... metric metric.
This all comes down to lazy, gutless management. Why take the time to get to know Dave and monitor the quality of Dave's work when we can just look at a spreadsheet at the end of the month? Managers prefer to tinker with automatic analysis software rather than manage.
Which is more fun, getting a better handle on what Dave is doing, or researching fancy new software tools that might get you all sorts of praise from metric-craving executives?
Dave's job, which was once about creating a quality product, now shifts to merely satisfying the metrics.
Application design (have someone think about everything in broad lines, set out a main architecture-model in ADVANCE.)
Iterative design.
A good project manager prioritizing and communicating current development shielding programmer from clients (who during the "waiting time", are fantasizing changes).
In contrast, in debugging and QA, free way between the client and the developer (more efficient and gives more motivation to the dev as to slave for )
Realistic expectations: don't get your devs running around doing "quick" jobs left and right while they're trying to keep a tight schedule.
Keep everybody current: short standup meeting in the morning
Motivate communication; devs tend to get absorbed in their coding-problem (nd prioritize being "productive") but forget to be a team
The right personality on the right segment of a project: developers have their strengths and their weaknesses.
...
I think we can keep recursing like this until someone returns 1
Writing for reuse can be excessive, but there are a number of reasons to move in that direction even if you don't intend to reuse that specific code block:
1) Unit Tests. If you abstract your functionality in a way that allows reuse, it also abstracts in for extremely easy unit testing. And unit testing will save you an incredible amount of effort in code maintenance.
2) Consistency. If you follow the same design pattern for all of your abstractions, all of your developers should be familiar with it. This makes it significantly easier for different developers to step into projects as the hopefully don't have to learn another person's style for abstraction.
3) Replacement and isolation. Need to implement a functional change? If your code is abstracted, like it would be for reuse, the functional change is limited to a single block, which is easily identifiable and if you're doing it right, unit-testable.
4) Just in case. Most of the time abstracted code doesn't get reused, and event when it does get reused it's usually a copy and paste job instead of a reference. Even so, if anyone ever does need the same functionality, it allows them to quickly rip off the exact piece they are looking for as opposed to trying to strip out your programs logic to get the tiny bit they want.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Personally I am always happy with the guy who can get things done with one line of code instead of a hundred, but what I really care about is that objective is met and we don't have a host of bugs that require 10 times the cost of the development just to maintain. Its not hard stuff but it does require common sense and a hard nosed attitude both of which can be scarce commodities these days.
I am also REALLY happy to have "that guy" that has absolutely shit productivity, but somehow manages to pick up on every time a "solution" is proposed by the rest of the team to a problem that doesn't exist or doesn't matter, and stops THEM from being really efficient at doing the wrong thing.
I'm also really happy to have "that girl" that doesn't seem to really be doing anything, but take her out of the team and everyone else starts floundering because she's actually constantly helping them be a lot more productive.
"Meeting the objective" is actually potentially just as bad as any other metric, because it depends on how you define the objective, and meeting it. What the customer asked? What the customer wanted? Or what the customer actually needed?