If you’ve been an engineer for any length of time, then you’ll probably recognize these truths about software.
It’s not predictable. Estimations are hard unless you’ve done it before. And if you’ve done it before, it already exists.
Requirements are in constant flux. The customer is always right, except when their telling you how to design a feature.
Shit happens. A library has a security vulnerability, a bug appears in the core algorithm or simply Patch Tuesday causes some unknown impact. Software is in constant change.
However, outside of the software bubble, management want to understand the engine is functioning well and want a graph going up and to the right.
We’ve moved beyond measuring lines of code and we’re starting to see sophisticated approaches such as DORA or the DX Core metrics which fill the void and provide measures that correlate with business success. Win! However, this doesn’t change the facts. Software development is messy and there aren’t any silver bullets to make it go faster.
Which is why I was delighted to see a paper entitled, “No silver bullets: Why understanding software cycle time is messy, not magic” which analyzes cycle time and concludes that “improving software delivery velocity likely requires systems-level thinking rather than individual-focused interventions”.
Cycle-time observations are noisy (and often misleading)
Cycle time is the duration between a ticket opening and a ticket closed, and at least one group of engineering leaders thought it was the most useful engineering productivity metric. I definitely see the attraction too - faster cycle time presumably means we try more things, which means we’ll validate more ideas with our customers and profit! Maybe…
The folks behind the paper analysed a data set of nearly 12000 contributors at over 200 organizations with the goal of finding the factors that impact cycle time, and how much variation is there? Data was analysed from both an individual and team perspective.
... continue reading