In a recent InfoQ podcast, Liran Haimovitch, CTO at Rookout, discussed the concept of “understandability” and how this relates to building modern software systems. Building on the concepts introduced in his recent InfoQ article, “Understandability: The Most Important Metric You’re Not Tracking”, he also discussed how complexity impacts a system’s understandability, and the benefits of live debugging tooling.
Haimovitch began by outlining the ideas behind understandability within software engineering, the foundations of which were borrowed from finance. At the core, understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner.
A system is understandable if it is complete, concise, clear, and organized.
When you speak of all the criteria, but especially completeness, then you must provide your engineers with visibility and information about all of those components. I mean, it doesn't help if you have the source code, but you don't know how the system is configured, or what records exist within the database.
In addition to providing access to the complete system, the information must be presented in a concise way; it is all too easy for engineers to experience cognitive overload when attempting to build a mental model of a system with hundreds of thousands of lines of code. Clarity and organization of such information further helps an engineer in understanding a system; adding appropriate metadata and providing effective methods to search and categorize information enables engineers to chunk ideas and attempt to understand components of the system in isolation.
There is a static and a dynamic component to understandability. Design time understandability is focused on architecture diagrams and code:
The static nature of the system [is] basically of how it was designed to be operated: what's the source code, what's the architecture diagram, what are the tables within the databases?
The runtime understandability is concentrated on data, data flows, and side effects. Haimovitch noted that the scale of the data within a system can impact understandability, and this can only be gathered dynamically:
If I have a [database] table, [does this] contain a hundred records, or a hundred million records? That's going to be very different, from a system perspective. And some of that information can only be gathered at runtime.
All architecture styles provide their own understandability challenges. Adopting a microservices-based architecture has not always provided the benefits being sought:
When it comes to microservices, you can see over the last decade or so, there has been so much movement, going smaller and smaller and smaller, and now actually the industry is moving back into larger components.
He argued that instead of architectural style, properties such as system complexity, software age, size of the team, employee turnover, and overall code quality and architectural quality are strongly correlated with understandability.
Understandability and observability are also linked. Observability is often more ops-driven, and focuses on understanding the state of the system from the outside and being able to ask questions about how the state occurred.
Observability comes from physics, which isn't finance, so it's an entirely different thing [compared to understandability]. But observability is about understanding the state of the system from the outside. And in a way, when you're trying to understand the state of the system, you assume you know the behavior of the system.
And usually when you're speaking to ops, to SREs, and sometimes even to sales and marketing, they kind of know the purpose of the system.
Haimovitch concluded the podcast by talking about tooling that can assist with understandability. In addition to the use of good documentation tooling and observability platforms, he also noted that live debugging tools, such as Rookout, can help. These types of tools, with the ability to dynamically add logging or set breakpoints in code that is executing, are focused on enabling developers to dynamically build an understanding of what is happening as a system runs in a production-like setting.