The 2021 Code Time Report from Software.com shows that developers code for only a fraction of the workday. Based on data from 250K+ developers in Software’s global community, developers code a median of 52 minutes per day — or about 4 hours and 21 minutes during a typical work week from Monday to Friday.
The data in the report stands in stark contrast to past survey data, which is often prone to respondent biases; for instance, in a 2019 ActiveState survey, roughly three out of four developers reported spending more than two hours per day coding. Data from the Code Time Report, which relies on real-time analytics from its plugins for VS Code, IntelliJ, and other code editors, indicates that only one out of every ten developers spend more than two hours per day coding.
These findings indicate that most engineering organizations still have a long way to go in terms of protecting developer time and improving software delivery. As the tech divide continues to grow, so does the chasm between the highest and lowest performing teams. Engineering leaders can close this divide by applying observability to development and benchmarking performance against elite performers.
SEE ALSO: Observability in 2022 – more open, more insight, more collaboration needed
Hidden bottlenecks are the hardest problems to solve
At most companies, developers face frequent disruptions, such as Slack notifications, which lead to involuntary context switching. Meetings break workdays into unusable blocks of time and take time away from more important tasks. Software’s data shows that developers spend nearly as much time in meetings as coding — about 48 minutes per day in meetings compared to 52 minutes coding. Even more time is spent planning and preparing for them.
Distractions and meetings are well-known and poorly-measured interruptions to developer flow. Lack of adequate tooling and slow processes are even more obvious, yet just as difficult to measure. Slow builds, limited environments, and manual testing break focus. Delays and handoffs between teams also disrupt the workday, requiring developers to spend their time filling out tickets and hunting down team members. At many companies, developers wait days or even weeks for a test environment, even if only to change a few lines of code.
What makes these bottlenecks particularly dangerous is that they remain largely hidden by the teams that face them. They are difficult to measure, and consequently, often unmeasured. As a result, they silently destroy code time for developers.
How to improve software delivery using DevOps metrics
Software development is a complex process with a lot of moving parts. Getting better visibility into the development lifecycle — namely, understanding where the biggest bottlenecks occur — is the most crucial step in improving software delivery.
The four key DORA metrics — lead time, delivery frequency, mean time to recover, and change failure rate — provide teams with a powerful starting point for measuring their development velocity and stability of their software. The DORA metrics have become the industry standard for benchmarking performance against other companies. According to the latest Accelerate State of DevOps Report, research of software development trends compiled by Google Cloud’s DevOps Research and Assessment team, elite engineering teams release code to production 6750x faster when compared to low performers. It takes elite teams less than an hour to go from commit to running in production, while low performing teams require more than six months to achieve the same.
Once teams understand their core metrics, the next step is to visualize the flow of work through the delivery pipeline and identify the single biggest constraint.
Most constraints correlate back to code time. For instance, a well-designed test pyramid — with a small number of end-to-end tests, fair number of integration tests, and exhaustive unit tests — provides developers with faster feedback earlier in the development life cycle. When developers can quickly test their code and feel confident in their code changes, they can spend more time writing code and less time waiting for builds and flaky tests.
Self-service tooling and automated deployment pipelines can also fix many of the biggest developer bottlenecks, winning back time for developers. Allowing developers to easily create and destroy environments can be a boon to developer productivity. It also frees up time for DevOps teams by removing the hassle of manual deployments, allowing them to focus on finding other ways to improve the team’s software delivery.
Constraints change over time. Growing teams, changing products, and evolving technologies mean engineering teams will always face new challenges. In today’s fast-paced world of software development, DevOps teams must be even more agile and focused than the teams they work with. Finding the biggest constraints faster by measuring DevOps metrics is the only sustainable way for development teams to consistently have an outsized impact in their organization.
The post How Measuring DevOps Metrics Improves Software Delivery appeared first on JAXenter.
Source : JAXenter