Tech, ExplainedCloud platforms and developer tools
Product

Developer productivity metrics

Measuring the real work inside each commit.

↑ DevOps
BEFORE ITAFTER ITDeveloperproductivity metricsBlueOptimaCOVERSCommit analysisEffort estimateVendor comparisonMaintainabilityCode repositorysuppliesevery commitIssue trackersuppliesticket timesA report that compares theestimated effort of each teamand each outside vendor.BEFORE ITAFTER ITDeveloperproductivity metricsBlueOptimaCOVERSCommitanalysisEffortestimateVendorcomparisonMaintainabilityCode repositorysuppliesevery commitIssue trackersuppliesticket timesA report thatcompares theestimatedeffort of eachteam and eachoutside vendor.BEFORE ITCode repository↓ supplies every commitIssue tracker↓ supplies ticket timesDeveloper productivity metricsBlueOptimaCommit analysisEffort estimateVendor comparisonMaintainabilityAFTER IT↓A report that compares the estimated effortof each team and each outside vendor.
The tool reads every commit from the repository and ticket times from the tracker, and reports the estimated effort of each team and each outside vendor.
opens a page inside this one a page in the same scene a page in another scene a concept page a label only, with no page

Developer productivity metrics are measurements of the work that software engineers do. One kind of tool analyses each change committed to a code repository, and estimates how much real work the change represents. Engineering leaders use these figures to compare their own teams, and also the IT services firms they hire to write code for them. The idea is contested: many engineers do not accept that their work can be measured from their code.

Why not simply count lines of code? Because lines say little about effort. One developer may add 2,000 lines by copying in a library, or by running a tool that writes code automatically. Another may spend three days finding a bug and change only four lines. A simple count rewards the first developer and punishes the second.

So these tools look deeper. They read every commit and set aside what took no effort: copied files, code generated by tools, and changes that only reformat the code. For the rest, they estimate the effort from how much the code's structure and logic changed. They also judge whether the new code will be easy to maintain. The result is a figure, often given in hours of effort.

Consider an insurance company in Gurugram that pays two IT services firms to build its customer app and its claims system. Each firm bills for 50 engineers. Over one quarter, the tool estimates about 6,800 hours of effort in the first firm's commits, and about 4,100 hours in the second firm's. It also flags that much of the second firm's code is hard to maintain. The insurer raises both figures in its next contract review with the second firm, and asks for the cause.

That is also where the argument begins. Much of an engineer's work never appears in a commit: design discussions, reviews of other people's code, helping a colleague, testing by hand. When people know they are measured on their commits, some change how they work so that the number rises, without the work improving. Critics also point out that an estimate is not a measurement.

Other teams measure delivery instead of effort. For instance, they count how often the team releases to production, and how many hours a change takes from commit to release. These figures come from the CI/CD pipeline and from the issue tracker, which records how long each ticket stays open. Many leaders use both kinds of measure together.

Talks to

Code repositoryIssue tracker

Who builds it

BlueOptima
Tech, Explained is a part of ingrid.fyi. Every page explains one piece of technology in plain words.