Objective data to measure software development is here, and it’s here to stay.
Join the DZone community and get the full member experience. Objective data to measure software development is here, and it’s here to stay. For a long time, the notion of using such data was thought to not really be possible. Thought leaders like Martin Fowler and Joel Spolsky basically said it couldn’t be done. Clearly, it’s a challenging task that frustrated software development managers everywhere. Shoot, I wrote an article way back when basically arguing that it is impossible to do. Well, I’d continue to argue that it was impossible to do. But now, with the rise of tooling like git, Jira, and other project management tools, it started becoming clear that the data is there to enable us to get a closer, more data-driven look at what is going on inside software development projects. That data just had to be revealed. And of course, people have started doing so. One of the most important and well-known results of that was done by the DevOps Research and Assessment organization — known commonly as DORA. They surveyed thousands of DevOps engineers and leaders over six years, coming up with a set of four metrics that were considered critical to the success of software development projects. The four DORA engineering metrics are: The first two metrics — Deployment Frequency and Mean Lead Time for Changes — measure the velocity of a team. MTTR and Change Failure rate are a measure of the quality and stability of a project. All four metrics can be derived from mining the tools that you are currently using. These four DORA engineering metrics are designed to allow software developers to align their work against the goals of the business. They have become the standard way for CTOs and VPs of Engineering to get a high-level overview of how their organizations are performing. By keeping an eye on the DORA metrics and organizing their work around improving them, development teams can ensure that they are doing the right things to move their projects, and more importantly their business, forward. Of course, understanding what the metrics actually measured and what they mean is necessary to make them useful. In addition, knowing the current state of these metrics is required for improving them as you move forward. So let’s take a look at these four key measures. Deployment Frequency measures the number of times that code is deployed into production. It’s usually reported in “Deployments Per Day”. Now, production can mean different things to different customers. For a SaaS company, it normally means actually delivering code to the production platform used by actual customers. For other companies, it might mean “made a version available for use by customers”. Increasing deployment frequency is an indication of team efficiency and confidence in their process. A team that can deploy more frequently is moving work through their pipeline faster and being more efficient about all of their work products. It tallies the total number of deployments an organization does in a single day. As noted, the definition of “deployment” can vary between organizations. This metric can be automated if a team has a Continuous Integration/Continuous Delivery(CI/CD) tool that provides an API into its activity. If you wish to improve your deployment frequency, you should invest in: Mean Lead Time for Changes is the average time it takes from code being committed to that code being released into production.
