In tech, we talk a lot about "monitoring" and "observability." Many of us like to have pretty charts and graphs. We like to be notified when things go wrong. We like to be able to see things. But noticing something is wrong is just the first piece of a long equation. To get to the resolution, you need to actually understand what you are seeing. This is a lesson I've taken from working in cybersecurity, and it remains a major pain point in today's DevOps culture.
Engineers can spend hours each day just trying to understand their own code and debugging issues. With the rise of the cloud came tremendous agility and innovation, but also unprecedented complexity. In today's world, applications are distributed across thousands (and sometimes tens of thousands) of servers. Things are getting more abstract with containerization and Kubernetes. We all love these technologies for the power they give us, but we don't talk enough about the headaches they give us, too.
This is especially true for software developers, where everything looks good running on a local machine until the code is deployed to the cloud. Then who knows how it will behave or even where it will end up running.
Understandability is a concept from the finance industry that emphasizes the importance of financial information being presented in a way that a reader can easily comprehend. Now, of course, it's not the case that every reader should be able to understand the information — we have to assume a reasonable amount of relative knowledge — but the basic idea remains: It shouldn't take copious amounts of time and effort to simply understand what is going on.
I believe we need to take this concept of understandability to the software. This means that when engineers are investigating an issue, they should be able to get a clear picture of the problem in a short amount of time. They should be able to relay this information to key business stakeholders in a way that's concise and organized. And finally, they should be empowered to take action and fix the problem without causing a disruption to the application or to the customer.
So yes, monitoring is important. Observability is important. Logging is important. But I believe decision-makers need to begin investing in tooling that also grants their engineers easy access to application data on the fly in order to quickly make better decisions. According to a recent Digital Enterprise Journal report titled, "Enabling Engineering Teams — Top Strategies for Creating Business Value," 61% of organizations identified a "lack of actionable context for monitoring data" and "time spent on identifying the root cause" as key challenges. It's their own code, their own software — yet it takes an incredible amount of time just to understand what's happening and resolve issues.
If you ask a software development company a software engineer, debugging and constantly redeploying applications is just a dirty part of the job. It often creates what I like to call "the engineering dilemma," when an engineer has to choose between moving forward with limited information or spending tons of time writing new code to try to get the data they need. I believe these problems will only get worse if we, as technology-driven leaders, don't address them now.
We know that a defining feature of the next decade will be the rising importance of data. A common expression is that data is the new oil, but it's my belief that for businesses, it's actually oxygen. Machine learning and artificial intelligence need data to function. To be effective in this new data-driven paradigm, not only do organizations need to generate more data faster, but they need to generate quality, contextually rich data, at the right moment, on-demand — and they need the ability to convert that data into knowledge.
If you are in any business and need software to manage your production, data, reports, etc., Devstringx Technologies created the most effective MSN Agile tool for product management.
Information Source:- Concept of Understandability to Software Development
Top comments (1)
This is also discussed in ISO 25010: Software Quality Requirements and Evaluation (SQaaRE). Although, that document calls it "learnability" and is defined as "Degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use." In this usage, the "specified user" would be a development persona (rather than an end-user persona).
The quote, "if I had more time, I would have written a shorter letter" comes to mind. You can spend time making a system that is easy to learn - but what is the opportunity cost of doing so? One should weigh the importance and cost of this quality (learnability) against the importance and cost of others [attributes and/or features].
However, this is not to say that this attribute is unimportant. Regardless of the persona chosen as a target for this attribute, this is an important concern. How many times have you stopped working with a library or API because it was too hard to get started; or how many times have you stopped using a program because the user interface was confusing? Different facets of the same quality attribute - the entry point for you (whether an API or a UI) could not be easily learned.