
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?"
Member since:
2008-05-26
This reminds me of a story about Bill Atkinson, who wrote many of the low-level graphics functions in the original Mac OS.
The management at Apple had just put in place a developer productivity metric based on "lines of code". A developer had to fill out the number of lines of code they had written at the end of the week.
Bill Atkinson had taken a week to rewrite some graphics functions. The rewrite had sped up those functions by a massive amount, cleaned up the code to make it more maintainable, and also had the side-effect of being 2000 lines of code shorter than previously.
When it came time to fill out the "number of lines of code written" form at the end of the week, he thought for a few moments and then wrote "-2000".
Shortly after that, they stopped asking him to fill out the form.