Leaky Abstraction
A leaky abstraction occurs when an abstraction intended to hide complexity unintentionally exposes some of that complexity to the user. This happens when:
- Unexpected Behavior: Users encounter issues not foreseen by the abstraction.
- Performance Issues: Different performance characteristics surface.
- Increased Complexity: Users need to understand underlying details to use the abstraction effectively.
- Inconsistent Results: Results vary depending on the underlying implementation.
Example: A file storage abstraction that covers both local and cloud storage might still require users to handle network errors or performance differences, thus exposing complexities it intended to hide.
Car Analogy for a Leaky Abstraction
Imagine you are driving a modern car that is supposed to abstract away all the complexities of its internal mechanisms. You just need to use the steering wheel, pedals, and gears without worrying about how the engine works, how fuel is injected, or how the braking system operates.
However, if the car was a leaky abstraction, you might encounter issues like:
-
Unexpected Behavior: Sometimes, when you press the accelerator, the car takes a few seconds to respond because it needs to adjust the fuel mixture. You didn't expect this delay because you thought pressing the accelerator should instantly speed up the car.
-
Performance Issues: On hot days, the car overheats, causing it to slow down or stop unexpectedly. You didn't anticipate needing to understand the cooling system's limitations when you just wanted to drive.
-
Increased Complexity: Occasionally, you need to manually adjust the fuel-to-air ratio using a knob on the dashboard to keep the engine running smoothly. This requires knowledge of engine mechanics, which the car's design was supposed to hide from you.
-
Inconsistent Results: The braking system works differently depending on whether you're driving on a flat road or downhill. You might need to pump the brakes in certain situations, which you wouldn't have expected if the abstraction was perfect.
Summary
A car, as an abstraction, is supposed to let you drive without thinking about the mechanics. But if it's a leaky abstraction, you end up dealing with delays, performance issues, and manual adjustments that you weren't supposed to worry about, much like how a leaky software abstraction exposes underlying complexities to the user.
Example of leaky abstraction making projects extremely hard to evolve:
Draw IO saying they dont accept external pull requests:
draw.io at one point had the following blurb in their README:
Open-source, not open-contribution
Similar to SQLite, diagrams.net is open source but closed to contributions.
The level of complexity of this project means that even simple changes can break a lot of other moving parts. The amount of testing required is far more than it first seems. If we were to receive a PR, we'd have to basically throw it away and write it how we want it to be implemented.
We are grateful for community involvement, bug reports, & feature requests. We do not wish to come off as anything but welcoming, however, we've made the decision to keep this project closed to contributions for the long term viability of the project.
Children