From an engineering perspective, SaaS is a far superior way to deliver software. By having full control over the entire value chain, and by limiting what has to be handed off to clients and partners, we can more aggressively optimize the process and gain massive benefits of scale. Simply put: this allows us, as software developers, to build better software.
But that’s not why our customers buy SaaS.
To use an analogy, our customers could buy traditional software applications, learn to operate them, and tailor them to fit their needs — similar to how one could furnish a kitchen, learn to cook, and prepare a 5-course meal. But most of us would prefer to simply order in that fancy meal, especially if we can afford it.
The point here is that for the vast majority of our clients, buying SaaS is not about a better product or a superior-tech stack, but rather about the shifting of responsibilities.
Shifting responsibilities means an entirely different mindset is separating the winners from the losers when it comes to SaaS. Successful SaaS companies focus on delivering business value to customers, instead of delivering high-quality software.
This change has manifested itself in multiple paradigm shifts that have occurred in the software development lifecycle over the last decade. The rise of Product Management and Growth Hacking, for instance, are driven by the focus on business value, and rely heavily on quantitative and qualitative feedback loops. The adoption of DevOps practices are all about creating a lean and mean value chain, delivering that value in high-frequency to the end customers, and adapting to the feedback quickly.
But somewhere along the way, software developers have been left behind. Why aren’t we seeing developers move closer to the end-users? Especially when there’s great progress being made in Ops, where Observability has empowered SREs to take charge of the applications serving customers, beyond just caring if they are up or down.
The New Category of Software Understandability
In the finance industry, Understandability is defined as a system’s ability to present information in a manner that can be easily comprehended by whoever is receiving the information. It requires that information should be organized, complete, clear and concise.
In the traditional world of software development, Understandability is usually achieved by ensuring the code is well documented, by tracking changes in source control management tools, and by enforcing knowledge sharing practices such as code reviews, style guides and naming conventions. The first and foremost tenant of software quality is naturally source-code quality, spawning idioms such as “Clean Code” and the “boy scout principle”. In that sense, “Shift Left” is just more of the same. It adds (important) attributes such as security and performance to the definition of high-quality software and gets engineers to own them.
But times are changing. Engineers should now focus more on the quality of the service their software is delivering, rather than only focus on the quality of the application itself. To do that, engineers must understand their applications like never before.
And so we define Software Understandability as the concept that “a system should be presented in such a way that an engineer can quickly and easily comprehend it.” In the world of SaaS, Understandability is a key element in the ability of engineers to provide both high quality applications, and to provide high quality service.
Challenges to Understandability
Bridging the gap between developers and production is quite a challenge. There are 3 main challenges organizations have to overcome to make it work.
1) The concept barrier. Developers spend their time working with source-code, source code management, and testing frameworks. Production is fleshed out in terms of servers, virtual machines, containers, logs, metrics, and traces. Breaking through the barrier requires educating developers on the one hand, but also with providing them with the data they need in a more appropriate manner.
2) Security and operational requirements. Developers are infamously known as a careless lot, and the teams in charge of keeping production up and running generally try to keep them away. Tools and processes must be set up to empower developers to get the information they need, without the possibility of service disruption due to human error.
3) The third and most important challenge has to do with the questions developers ask. Unlike other data consumers within the organization, each and every developer will ask a different question every day. This means changes to data collection should be carried out in seconds, rather than days or months. Very few data pipelines support that level of agility.
Better Understandability Means Happier Customers
In a recent whitepaper from the analyst firm Intellyx titled Why Understandability is Essential to Every Software Developer, Principal Analyst Jason Bloomberg writes that “Developers need better information about how their code is behaving in production – ideally on a line-by-line basis. And they need this information without having to recompile and redeploy the code. What they need is Understandability – information about running code sufficient to understand its behavior on a line-by-line basis, regardless of the complexity of the production environment.”
The most important thing, at the end of the day, is the customer experience. Overcoming the challenges to Understandability will allow us, as engineers and SaaS providers, to deliver an incredible service. Focusing on the business needs of our customers — perhaps even more than on the code itself — is what will separate the winners and losers in the future of SaaS.