The “impossible” four-minute mile was accomplished by Sir Roger Bannister on a windy day in May of 1954. Now you can do it too. It is not that complicated when you think about it: just run four consecutive quarter-mile sprints in under sixty seconds each.

Okay, so maybe the actual execution isn’t trivial. But his approach to the problem correlates directly to successful software delivery: measure, manage, execute.

Bannister pioneered measurement, assessment and adjustment in competitive athletics. He studied how his body reacted to exhaustion. He modified his running technique to eliminate unnecessary movements. And he created a specific plan to track his progress and achieve his goal of being the fastest man in the world.

So how does all this relate to the software industry?

We all have development goals that can seem as daunting as the four-minute mile. All too often, our attempts at sprinting devolve into a death march to failure.

One reason, I propose, is that we are failing to capture what efforts are working and what efforts are failing. We often know very little about the actual source code we produce. And we rarely invest resources into measuring important data that could materially affect the way we manage our teams.

Bannister set up a regimen of ten quarter-mile sprints, meticulously measuring his results until he could accomplish them all in sixty seconds each. He recorded his times and tracked his progress. He adjusted his strategy based on the results.

What are you measuring related to the code generated by your teams?

Do you know how much code is regularly produced? Do you know how complex the code is? Have you calculated test coverage? Do you have visibility into module dependencies? What is the percentage of duplicated code? How long does it take to generate a complete build? What about a complete build on an entirely new machine?

Have you established internal targets for any of these metrics?

At Stelligent, we help companies measure their development effectiveness based on the Stelligent Quality Risk Index. A significant part of our expertise is working with our customers to determine which measurements are applicable to their individual needs. Then (just as in Bannister’s case) we record and track progress and help adjust the strategy to achieve their business goals.

The end goal is not to create less complex code, reduce defects or lower integration times – these are just the positive time results of quarter-mile sprints. The end goal is to accelerate delivery of reliable software. But you cannot achieve that larger goal by simply showing up at the track and running as fast as you can. You have to measure, plan, train and improve execution.

And it all starts with a simple question: how well do you run the quarter-mile and what measured factors are preventing you from running faster?