Considerations for Effective Developer Productivity Measurement

Let’s begin with an obvious question: Is developer productivity possibly to measure? Is it even possible to measure developer productivity with any degree of accuracy? After all, there are so many variables and every situation has its own – often unique – challenges.

The short answer is that yes, it is possible to effectively measure developer productivity, though a few conditions must be acknowledged, including:

• No one size fits all – this obvious fact still needs to be considered up front.
• The challenges can (and will) differ from one project to the next.
• As each project (and each challenge) will be dynamic, the process needs constant review and re-calibration.
• Productivity involves not just developers, but the entire delivery organization.

The Importance of Balance

It’s also important to stress the concept of balance: the balance between the qualitative aspects and the quantitative aspects of the development process:

Quantitative:

• What are the developer’s productivity metrics?
• What are the developer’s quality metrics?
• What are the overall operational metrics?

Qualitative:

• What’s the level of motivation?
• Is there a sense of teamwork and contributing to the team’s goals?
• Is there a sense of initiative and creativity in tackling challenges?

In the past, attempts at productivity measurement were not very effective. Counting lines of code as a metric, for example, is never very accurate and can even be gimmicked.

Even using story points can often result in arguments among team members over how many points to award for various stories.

Such examples point to the value of strong, experienced technical leadership.

Some KPI metrics to be considered include:

• Code/Development metrics: code analysis results
• Testing/QA metrics: defects, cases, scenarios
• Process/Operational metrics: status reporting, requirements, acceptance criteria

Mind Your Parameters

When measuring and assessing the various parameters such as Cost, Quality, Schedule and Code Quality, keep in mind that how you prioritize each of them will depend on the nature of your organization.

For example, if you’re an early-stage organization working hard to establish yourself within a mature market, speed to launch may be a high priority. You may even be able to justify taking on some technical debt that will demand your attention down the road.

Technical debt accrues when developers take shortcuts in order to boost the development speed. The result of technical debt is that it may later result in further costs in fixes, but that debt may be justified if it enables your organization to launch a product into the market early.

If your organization is further along, test coverage and quality might be the most important parameters.

In any case, in establishing the process of measuring developer productivity, it’s critical to know exactly where your organization is with respect to your overall goals, then to set and plan and implement a strategy for measuring.

In our next article, discover the aspects of the specific metrics and how to approach them, both in terms of your current project and planning for projects in the future.