According to the 2020 State of Software Quality report produced by OverOps, two out of three software developers estimate they spend at least one day per week troubleshooting their code. How that translates to money lost is hard to calculate (and certainly varies from business to business), but analyst firm Digital Enterprise Journal estimates that organizations are losing $2,129,000 per month on average due to delays in application releases.
As developers, we’ve mostly accepted that debugging code is part of our workflow. We write endless log lines, write new code to get new data, and sometimes push forward without context just to avoid this tedious process. If we take a step back, however, we can realize how insane it is that we spend so much time just trying to understand our own software! Why can’t we as developers just click a button and get the data we need, on the fly, from production systems?
The Issues with Traditional Debugging
When we’re debugging with traditional tools, we too often have to stop the application and go through additional release cycles in order to get the data we need. We also have to write additional code, just to better understand our existing code, which adds significant overhead costs and unnecessary security risks. These problems are magnified with the rise of distributed teams, systems, and applications. In today’s world, a single VM can have multiple containers running hundreds of apps! Microservices means all of these services are broken up, but yet still depend on one another, making it impossible for any one person or even team to understand the entire system.
When a bug is found and reported within an application, developers will often begin the debugging process by looking for clues as to the root cause, by either doing log file analysis or by stepping through the code with a debugger in their local IDE. The actual fix to the code, more often than not, turns out to be simple. The developer spends most of their time simply trying to get the necessary data.
That’s why, to date, our primary focus at Rookout has been to make it easy to extract data from live systems with a click of a button. By allowing developers to capture snapshots of data as the application is running in its native environment, exactly where the defect occurs, it becomes a much simpler process to diagnose the issue. When compared to the hours typically spent by organizations recreating environments, either locally or in shared test environments (which never fully mirror production environments), the case for adopting a modern debugging solution becomes much easier to make.
But a question we’ve been getting from senior developer managers is how do we know exactly where the most time is being wasted debugging? Well, that’s the question we are helping companies answer with the new Live Debugging Heatmap.
Introducing the Live Debugging Heatmap
With the general availability of the Live Debugging Heatmap, developers and management can now have a birds-eye view of where the most problematic applications are located.
From talking with dev teams across various industries, what happens is that a single siloed team can spend hours debugging an application, without even knowing that other teams are wasting time on that same application.
The heatmap provides a quick and visual way to have a more comprehensive understanding of where the most time is being wasted debugging, which developers dare to debug in production, and how much time is saved by using Rookout vs traditional debugging tools.
Yan Davidovsky, engineering director at Amdocs, writes that they are “leveraging Rookout’s new heatmap to give cross-team visibility into where developers are wasting the most time.” He goes on to note that his team spends “many hours each week debugging code,” and that “anything that helps locate exactly where that time is being spent, and also helps measure the ROI of those efforts, is invaluable.”
By monitoring the heatmap, DevOps teams can also make more informed decisions when reviewing their application architecture and technology stack. Perhaps you are debating converting a monolith to microservices, or maybe there’s a specific platform you are suspicious is causing undue technical debt — the new Live Debugging Heatmap can help you make better-informed decisions to embrace or move away from specific technologies.