Measuring Software Development Productivity

I stumbled upon this question in Stackoverflow regarding software development productivity. It’s a hard question to answer. Of course, productivity cannot be measured by the volume of codes a novice developer writes. Nor it can be measured by the too few awesome codes an experienced developer writes. It’s the marriage of both: developer productivity = code quality * code frequency.

In NESV, we strive hard to ensure a productive developer environment. We invest on tools to help developers solve problems. These tools also help us track their work. Additionally, we adapt processes and conventions to create a foundation in solving problems. Lastly, together with tools and processes, we measure certain facets of development; we have our own key performance indicators (KPIs) to observe, track, and ultimately react to possible problems affecting developers’ productivity. Below are some of our KPIs and how we get the data:

Number of resolved (or missed) issues (tickets)
We use Jira for issue tracking religiously. We have a “no ticket, no movement” policy. This is how we can track with certainty the workload of a developer including the status of assigned tasks. That’s why resolved and missed tickets are among the pillars of our KPI. This gives us an overall picture of how a project or the team is performing.

Number of reopened tickets
Another critical data we pull from Jira is reopened tickets. This highlights several areas we want to measure: QA result, comfort level of the developer, severity of the ticket, handling time, blockers of the ticket, etc. This is important in measuring the quality of code that developers write.

Number of code commits
We use Git as our version management tool and Bitbucket as our code repository. We have implemented several checkpoints in Bitbucket to capture important data points. Arguably the most important, is the frequency of code commit. Instead of line of codes, we use code commit as one of the pointers to developer’s productivity. Coupled with code review (more below), it’s a very telling tool to track the amount and quality of work done.

Code review feedbacks (or lack thereof)
Our code review happens after a developer checks in their code to their branch (not to a main branch). Bitbucket has a facility to apply feedback on committed codes. Code reviewers strictly implement our code conventions. We also include code branching and versioning as part of the review.

Number of pull requests
Merging back to a main branch e.g. `developer` or `production` branch requires a pull request and pull request requires explicit approval. The purpose of this is two-fold: we can monitor how much of a developer’s code make it through the production and second, how much of those code that gets through we have to maintain.