One of the most useful ways for engineers to manage complexity within a software system is through software abstractive mechanisms. Well-functioning software abstractions create an opportunity for teams to reason about a software system without having to understand every aspect of the system down to the lowest level of detail.
When engineers find leaking software abstractions during production code development, the problems created by those leaks can cause a decline in system reliability due to bugs, a decline in system performance due to greater complexity in the underlying software abstraction, and an increase in maintenance costs due to the higher complexity of these types of software abstractions.
When engineering teams understand the leaking point(s) of a software abstraction, they have an opportunity to reduce or eliminate the potential for those types of software problems to be introduced into their systems. By recognizing the type of software abstractions that leak, engineering teams can address those leaks and develop more reliable software and avoid costly surprises when developing software under adverse conditions.
What Are Abstractions and Why We Rely on Them
Abstraction is a way for software to provide a simpler, more accessible interface to developers than the actual underlying complexity. Abstractions come in many different forms, such as programming language syntax, libraries, Object-Relational Mapping (ORM), Application Programming Interface (API), service layer, or a complete framework. Developers can use an abstraction to create software without worrying about how it actually works at the hardware level, which allows for faster software creation than if all of the programming and implementation processes started from scratch without any form of abstraction. Developers can use a specific model rather than relying on low-level programming techniques, which is a key concept in the evolving landscape of software development.
When using an abstraction to write software, developers have a specific model that they develop their code from, rather than relying on low-level programming techniques. This allows them to develop software much more quickly than if they were to start from a complete or semi-complete understanding of a hardware platform.
While the advantage of abstraction is that it hides the naked truth of how complex systems really work, it also adds multiple levels of indirection to the development process. Therefore, by the very nature of abstraction, assumptions are introduced into the software. When the assumptions made by a developer when developing an abstraction do not match what actually occurs in the real world, the abstraction fails and leaks information developers aren't prepared to handle. This results in hidden complexity.
What “Leaky Abstractions” Actually Are
The term "leaky abstraction" was used by Joel Spolsky and refers to abstractions that do not completely hide their inner workings. An abstraction leaks when a user must be familiar with how it works to use it correctly or to troubleshoot any issues that occur in day-to-day use.
With a leaky abstraction, a developer does not receive a "black box" experience where there are no internal mechanisms visible. The leaky abstraction of a software application has been referred to by many developers, including us, as having a design that exposes the underlying details of the operating system. By exposing internal implementation details of a system, developers are forced to relearn aspects of a system that should have been hidden from view.
A practical use of a leaky abstraction is to work with an ORM (Object Relational Mapping). The ORM creates a layer of abstraction above the database, allowing you to access tables more simply, but when the database has many processing requests and the performance is heavily degraded, the ORM may create poorly written SQL. Thus, for debugging purposes, the developer needs to know how the SQL works and how it is processed by the database knowledge that the developer has lost through the ORM abstraction.
By utilizing a leaky abstraction, there are added maintenance costs for the application once it is running in a real environment. Additionally, developers may not deliver all of the expected features to their customers, or overall performance will be negatively impacted.
Real‑World Forms of Abstraction Leaks
In practical terms, abstraction leaks manifest themselves in real-world software applications. By recognizing recurring patterns identified by engineers, they can predict where complexity will show itself and find solutions for it before the problems arise during production.
Database Abstraction And ORM
By establishing a connection to objects instead of SQL statements, ORM (Object-Relational Mappers) create an interface for the developer, enabling them to operate with their code without ever writing SQL directly. In production use, however, the ORM may generate less-than-efficient queries, and in addition, the ORM will abstract away the method by which the application actually obtains the data. This means that developers who are using ORM will find themselves, either after an execution, having to switch back to pure SQL, or manipulate their business logic, avoiding the abstraction altogether.
Ultimately this abstraction leakage will only come to light when querying the database causes delays in production, or when they encounter some edge case that is not covered by unit testing. Developers should choose the right technology stacks for software development to reduce these risks. For example, working with an experienced Laravel development company can help ensure optimized database queries and better abstraction handling in production systems.
Caching Layers
The purpose of a caching layer is to hide the cost and variability of accessing a database, but again, there is a significant risk that developers will unknowingly assume an invalidation strategy when creating business logic. The complexity of managing a diverse range of invalidation strategies and their associated datasets creates new layers of complexity, rather than providing a mechanism to hide it from view, as both require additional levels of complexity when combined.
Third-Party Client Libraries
Many third-party client libraries, such as third-party SDKs, have added additional abstraction layers on top of the API request time to add built-in retry and rate-limiting feature capabilities. Consequently, when the developer does not consider how these features might behave and influence his/her ability to develop under heavy load conditions, they may cause the developer unexpected consequences during production run time. Just as before, developers must have an understanding of the underlying logic of the SDK in order to solve these types of problems, which is a clear indication of abstraction leakage. Choosing the right best IDE for software helps maintain efficiency while working with complex abstractions.
Realizing the limitations of abstractions will enable teams to build scalable systems that have consistent and reliable performance under load and that will not produce unwanted surprises when the abstraction breaks in production.
Why Leaky Abstractions Happen, What are the Root Causes
Failure of an abstraction does not necessarily indicate poor engineering judgement but it does represent that the abstraction is trying to describe something that is too complex for that abstraction to accurately address. The complexity of this system continues to change and the root causes of these leaks can be identified. By being able to determine the root cause of these leaks, the engineering teams are more likely to develop future systems with fewer occurrences of unexpected leaking during production runtime
Intrinsic Complexity of Systems
Every modern software program has several layers of code, integrations with other programs, and many moving parts that can interact with each other in unpredictable ways. Abstractions help simplify what is visible to users in order to make software easier to use, but even the best abstraction cannot eliminate all variability (particularly when a system is operating at large volumes).
For many software programs today, performance restrictions, real world distributions, and patterns of production traffic will vary greatly from how the software was tested in a controlled environment. Once those unforeseen variables become apparent to the testing team, the abstraction’s false sense of simplicity will uncover much of the system’s intrinsic complexity.
Mismatched Expectations
When developing, many developers will build and test their software abstractions with the assumption the behaviour of their abstraction is consistent across various environments and usage patterns. During the periods of testing (or staging) their software will behave in accordance with the testing they performed, validating their conclusion that their software was an effective and complete abstraction.
However, when their assumptions about how their application works fail for example, when a cache behaves differently during high-traffic times compared to low-traffic times or when caching is affected by high levels of concurrency the abstraction becomes compromised. When these “leaks” occur, the individual developer must take the time to learn other aspects of a system’s internal workings that were never intended for them to manage directly.
Hidden Dependencies
Some abstractions are built on top of other elements of a solution specifically, other levels of the hierarchy of a solution, services and/or systems that operate as a unit with other elements of a solution but do not expose their interfaces. These less visible dependencies can add risk, as the way they behave may change without impacting the way that an abstraction behaves.
When a dependency fails, becomes impaired or changes, the unexpected outcome will occur on higher layers of the solution. Having this visibility into including dependencies in the overall complexity of your abstractions lightens the burden associated with developing solutions; but can also illustrate how even with "cleaning up" abstractions, hidden details or aspects of a solution still exist within a more complex abstraction.
To create resilient software systems, it is important to understand why abstractions leak. When the developer places special expectations to not rely on complexity, unrealistic assumptions, and unknown dependencies, they will invariably run into problems that lead to negative impacts during production usage of their applications. The best way for an engineer to design effective abstractions is to recognize how their abstracts will likely fail and minimize the amount of production failure for their abstracts.
The Cost of Hidden Complexity
Poor quality software can have measurable long-term consequences. One of the most serious of these consequences is that teams often spend an inordinate amount of their time and resources trying to understand how their software is functioning internally (due to leaky abstraction) instead of delivering business value to their customers. Therefore, rather than being a "one-time" obstacle that is dealt with in the short term, complexity can result in extremely high maintenance costs long after a system has been delivered.
1. Maintenance Costs, Most of the Cost of Software Over Its Life Cycle:
Research shows that the cost of maintaining a software system will consume between 50%-80% of the total cost of the software over the life cycle of the system, which is far greater than the initial cost of developing the software.
2. Legacy Issues Slow Down Team Development of New Features:
Several surveys have shown that developers spend a substantial portion of their working hours dealing with legacy-system issues rather than working on new features; in fact, a common survey finding is that many developers, on average, spend over thirty percent of their working hours addressing these issues.
3. Defects in Low-Quality Code
Quantitative studies reveal that low-quality code has up to 15 times more defects than high-quality code, and any time spent fixing defects in those low-quality codebases takes an average of 124% longer to fix than high-quality codebases.
Thus, the findings above illustrate that when developers need to understand the internals of their code due to the presence of hidden complexity within the codebase, which should not be necessary if their abstractions were strictly adhered to, the result is that more defects are created, fixing defects takes longer, and that maintenance will cost more in the future.
How to Detect Leaks in Your Codebase
Abstraction leaks are not consistently evident until the system is applied under pressure. Early detection involves observing how an abstraction operates across different environments, through varying amounts of data, and through actual usage patterns instead of looking at a single function.
Monitoring & Profiling Performance Metrics
By observing how an abstraction operates within production using profiling and monitoring tools, teams can identify an abstraction leak if the abstraction performs poorly under given conditions.
Boundary & Integration Testing
Unit tests validate that units of behavior work correctly in isolation. A Boundary Test or Integration Test detects abstraction leaks when an abstraction attempts to interact with real-life systems. As with Performance Metrics & Monitoring, teams must test the abstraction under realistic usage scenarios with real-world data to gain insight into its performance.
Observability & Tracing
By using comprehensive logging and distributed tracking, team members can better understand the paths of an operation through various levels of abstraction, and may even uncover dependencies or behaviour that were not previously known, especially if there is a dependency that is not apparent from the top-level view of abstraction.
If abstraction leak issues are identified early in the process, teams can manage any hidden challenges associated with those leaks before they become visible to the end user in a production environment. Specific testing and visibility strategies allow teams to improve an abstraction rather than starting from scratch. In this way, teams can build, manage, and operate reliable systems.
Mitigation and Fix Strategies
Identifying where abstraction leaks can happen (this is the goal) is not meant to remove all abstraction, but to strengthen them by making behaviour explicit, reducing implicit or unremovable assumptions and improving the manner in which abstractions may evolve throughout time.
Provide Clarity for Abstraction Contracts
Document what an abstraction is and what it isn't; contracts are explicit and allow for team members to identify where hidden behaviour will develop from.
Constrain the Number of Escape Hatches
Use a limited number of escape hatches to describe the way to escape from an abstraction, as generally too many indicate that the abstraction either does not work or that you need to either stop using them completely or begin using them as intended.
Incremental Refactoring
Improvements can now be made gradually and incrementally rather than writing a brand new system, and developers with knowledge from best software architect certifications are better equipped to isolate the complexity as they go.
Performance-Aware Design
In situations where scale and/or latency are important, design an abstraction based around performance and measure its performance under a production-like scenario.
By allowing teams to add to existing abstractions incrementally they regain control of complexity without destabilizing production systems. Over time these small incremental changes lead to a more predictable behaviour, improved performance, and easier to maintain codebase.
When Breaking an Abstraction Is Justified
Abstracting away a lower-level interface into a higher-level interface provides the benefits of having a single layer through which a developer interacts with the lower level interfaces. Abstractions can sometimes make it harder for developers to understand how to best optimize their application and improve its performance, as well as make it harder to tune the application in a reliable manner; in some instances, this fracturing of abstraction leads to the developer having to break off from the abstraction and create a different means of accessing the database by writing the SQL directly rather than relying on the ORM-generated queries.
When developers choose to break an abstraction, it should be with intention; such decisions are typically made in response to performance concerns that the developer has identified through testing or monitoring and to address those concerns as soon as possible with a solution that provides immediate benefit. Developers who choose to implement changes that involve the breaking of an abstraction should always document and maintain those changes to ensure that their overall software architecture remains intact.
Lessons for Engineering Teams
Leaky abstractions show us that we can't remove complexity from our systems but can manage it by using solid engineering practices (for example: documenting thoroughly, testing well, measuring performance, and improving incrementally) to identify and reduce the impact of hidden complexity before it becomes long-term technical debt.
By helping engineers develop their intuition regarding system behavior around the boundaries of the entire system rather than looking just at the isolated components of the system will ultimately help them develop a more robust understanding of where leaks might happen over time, leading to a better-designed abstraction, fewer surprises in production, and greater ability for software systems to adapt as they increase in size and complexity.
Conclusion
The presence of leaky abstractions does not indicate a mistake made by an engineer; rather, they illustrate the complex nature of software products. Although an engineer has designed his or her abstraction well, the boundaries drawn by the abstraction will be tested as the application is subjected to conditions that may or may not be expected.
Engineering teams can use knowledge of the causes of leaking abstractions to identify potential areas for success and failure. By establishing clear boundaries, engineering teams should create realistic expectations from their products and develop the ability to respond to problems quickly, with minimal risk. The main goal of an engineering team is not necessarily to eliminate all complexity; however, to develop and maintain a software solution with confidence that it will continue to be secure, supportable, and usable as it grows.
Sign in to leave a comment.