According to research recently published by Digital Enterprise Journal, organizations are losing $2,129,000 per month, on average, due to delays in application releases. This creates a tough choice for development teams, who are depending on fresh logs and metrics from those releases to guide their data-driven development processes forward.

In other words, there’s what I like to call the engineer’s dilemma: Is it better to fly slow or fly blind? This dilemma is caused by a simple paradox: engineers need data in order to write better code, but they need to write more code in order to retrieve that data. Should they continue with the data they have? Or should they slow down until the data becomes available to move forward?

RELATED CONTENT: 
Observability: It’s all about the data
APM, AIOps and Observability
APM: What it means in today’s complex software world

But as developers, is this really a choice we should have to make? In an ideal world, we’d be able to get the data we needed on-demand, without having to write new code or wait for long re-deployment cycles. In this world, there is no choosing between flying slow or flying blind: you can move fast because you have instant access to the data you need, when you need it.

This is why I’ve been thinking a lot about the importance of Understandability. In DevOps, we hear all the time about observability, about monitoring. But how have we looked past the simple problem that understanding our own software is an ever-growing challenge?

The truth is that software engineers are not getting data in the resolution they need from traditional observability and monitoring tools. They were built to minimize service disruption and trigger alerts when something goes wrong. They were built for auditing and logging. As developers, we can’t always settle for logs, metrics and spans. We need to know exactly where a specific function was called, and with what arguments. We need to know the exact inputs and outputs of the system so that we can further iterate on improving it. And with the rise of microservices, it’s more important than ever that we understand how our code integrates with first, second, and third-party services.

The concept of Understandability is extremely important in the finance industry, and advocates for information to be complete, concise, clear, and organized. We should apply this logic in the world of software. I’ve seen time and again engineers make poor choices because they had limited or overly-complex information. All too often, we end up taking calculated risks due to lack of data which could have been there for us.

Three things to look for in your Understandability solution:

Speed
Fast access to data eliminates the dilemma of ‘flying slow or flying blind’ — Instead you can fly fast and with laser-focused vision! No more endless logging — what I like to call Logging FOMO — just quick access to context-rich data whenever you need it.

Simplicity
The traditional processes that developers go through to obtain data are lengthy and complex. Often there are many steps such as writing more code, getting it approved by others, testing, and redeploying. The complexity of this process, not to mention the sheer amount of time spent on it, creates unnecessary friction. Having a simple Understandability tool will save everyone time, money, and headaches.

Security
While decision-makers in the company may agree that having an Understandability solution in place is important, they may have legitimate security concerns. Make sure any tool you adopt to help with Understandability has enterprise-grade security controls and compliances such as SOC II, ISO 27001, and GDPR.