People in software development tend to have mixed feelings about metrics.

On one hand, many developers have computer science or engineering backgrounds and are comfortable with numbers. They use metrics to find opportunities for optimization. Just as you can’t make a compiler faster unless you know how long it takes and where, you can’t make the software delivery process faster unless you can figure out the bottlenecks. Software engineering metrics, correctly applied, can be a tool for improving the work life of every developer.

But on the other hand, anyone who’s been in the profession for a few years is certain to have run into more harmful uses of metrics. When software managers abdicate their performance review responsibilities to a dashboard, nobody wins. A reward or punishment behind certain numbers will focus developer attention — usually on the wrong things and to the detriment of the product. The odious management fad of stack ranking turns even highly functioning software teams into zero-sum buckets of crabs where team members succeed by hindering their coworkers rather than by helping the teams win.

The Maturation Of Software Development Metrics

As successive generations understand the value of quantifying the software development process, they reinvent software developer metrics.

Early metrics used lines of code as a proxy for productivity. More recently, companies started from different points of view: Swarmia said they’d let you see work in progress at a glance and know where time really goes, while LinearB offered to provide instant visibility into your work-from-home development teams. DX brought a developer experience perspective, while Jellyfish focused on developer productivity and aligning engineering with business.

Many of these platforms adopted behavioral economics techniques for nudging people towards the right decision. Today, standalone software metrics platforms often call themselves software engineering insights (SEI) but also find themselves doing value stream management (VSM), which extends beyond the SDLC.

Although VSM appeals to leaders, the term itself does not resonate with developers. Despite that, building alignment with the rest of the business is critical, no matter what you call it. There’s nothing worse than when a project you’ve poured your heart and soul into gets cancelled because it “no longer matches our priorities.” Smart developers aim to understand why they’re building what they build and how that fits into the overall goals of the business — that’s good for them, their customers, and the organization.

It’s All About AI And The Economy

It’s obvious we’re in an AI bubble, and organizations are preparing for tighter economic times. As developers adopt AI, business leaders struggle with the question: Is it worth what we pay? Can we get metrics to show ROI?

The jury is out on whether developers get better long-term results with AI. They can generate more code faster, but are they creating better features? Do they drive revenue, reduce time to market, and improve quality? There have been improvements to developer experience using AI, but developer productivity doesn’t match the claims of AI vendors. That has put SEI front and center again, with all the dangers that misapplied metrics can cause.

I’ve expanded my coverage from developer experience to its neighbor, SEI, to tackle these issues. If you’ve got questions, get in touch with me. If you’re a vendor that has an SEI solution, let’s talk. I hope to hear from you!