Frank Carver's Punch Barrel

The topic of assessing the productivity of developers has cropped up again at work. Unfortunately, it is in danger of falling into the same old traps that such efforts always do.

• Attempting to measure individual productivity makes little little sense in a team context. Team members contribute in many more ways than just writing code: reviewing, mentoring, estimating, liaising with stakeholders and customers, improving process and generally assisting the team. Assessing, and thereby encouraging concentration on, individual productivity runs a great risk of reducing
• Attempting to measure team productivity makes little sense in a company context. Unless the company consists solely of a development team, the impact of choices made and work done by other parts of the company can dwarf any variation in development throughput. In the simplest terms, any development work is pointless if it is not developing the best solution for the whole company, yet the choice of what to work on typically comes from outside the development team.
• And finally, there is no simple way of measuring software productivity outside the context of the rest of the organization. Lines of code is a laughable measure as it says absolutely nothing about the usefulness, quality or maintenance cost of the code, or how much that work contributes to reducing future costs. Function points initially sound more plausible but are easily impacted by meetings and other time sinks, and still say nothing about key aspects of the code. Bug and rework rates often depend more on the acceptance criteria and release policy than the code itself.

The most important thing to remember is that whatever you choose to measure will be optimised, and everything else will become unimportant. Measuring lines of code results in bigger, less maintainable, software; measuring function points results in quantity at the expense of quality; measuring bugs and rework results in ass-covering at the expense of throughput.

So. Before you naively instigate a productivity measurement initiative, think long and hard about what you really want to improve.

InfoQ: Opinions: Measuring Programmers’ Productivity