Can I have another abstraction, please?

For me, abstraction is part of what makes computers magical. As often as I can, I sneak in the famous saying:

"All problems in computer science can be solved by another abstraction."

Reflecting on my fondness for the concept of abstractions, it's not surprising that I work on something like Enterspeed. Enterspeed is, first and foremost, a way to hide the concept of scalability from the developer. But secondly, it serves as an abstraction of the CMS or whatever source system you have. In this blog post, I'll geek out on the topic of abstraction and discuss why abstractions are both indispensable and tricky.

The origin

The saying I quoted to begin with is attributed to David Wheeler. As the inventor of the subroutine, Wheeler should know a thing or two about abstractions. I decided to dig into the origin of the saying. To my surprise, I learnt that the original quote is:

"All problems in computer science can be solved by another level of indirection."

This led me down a small rabbit hole to understand the difference between indirection and abstraction. In short, indirection is about location, whereas abstraction is about creating new concepts that hide complexity.

With this matter clarified, let's discuss the missing part of the quote. Wheeler completed his quote with another phrase:

"But that usually will create another problem."

Abstractions have always been a double-edged sword. On one hand, they are the foundation of modern computing; on the other, they introduce new complexities.

The magic of abstractions

The duality of abstractions is magical. Abstractions are the foundation of modern computing. The examples are many, including the use of high-level programming languages like C#, so I don't need to know anything about managing memory or machine code. Everything is abstracted away so that I can focus on delivering value.

Another example is the web browser. Imagine if I needed to know the HTTP protocol to surf the web! Or programme a GPU to build a webpage when I can simply use HTML. In both cases, the browser does most of the work, abstracting away the details.

An example in the realm of indirection is Dependency Injection. The notion of creating an abstraction for potentially swapping out a data store or CMS platform may seem great on paper, but it's often challenging to fully hide all details. However, dependency injection provides other benefits, like facilitating unit testing through allowing for data store mocking.

Law of leaky abstractions

But what makes it even more magical is when abstractions break down. When something doesn't work as expected, you often  need to look behind the "magical" layer to understand the underlying concepts.

Joel Spolsky once formulated the Law of Leaky Abstractions:

"All non-trivial abstractions, to some degree, are leaky."

What this means is that it's inherently impossible to completely erase the underlying concepts beneath the abstraction. Understanding the HTTP protocol when the browser doesn't behave as expected can be invaluable.

Abstractions are a compromise

Both users and software engineers rely on abstractions. However, as a software engineer, understanding what happens behind the abstraction is crucial. David Wheeler’s famous aphorism reminds us that we gain flexibility, maintainability, and effectiveness with abstractions, though they also introduce complexity and hidden bugs.

Enterspeed's abstraction magic – or the illusion thereof?

Reflecting on Enterspeed as an abstraction over a CMS or other backend systems, you've got to evaluate the pros and cons. Enterspeed adds a new layer atop the source system to introduce a new storage and delivery mechanism, aimed at gaining speed and operational decoupling. However, like all magic tricks, there's an element of illusion.

I don't believe that Enterspeed will make the source system completely disappear, as the data model of the source system is not abstracted away. On the contrary, we want to have the raw data model from the source system, so it can be transformed and combined within Enterspeed.

Switching from one CMS to another is not a drop-in replacement, as it's challenging to abstract away the data model. The complexity introduced by the abstraction is a worthwhile compromise, given the benefits of combining different data sources and delivering high-performance API requests.

Another abstraction is often the answer but beware of leaks and inherent complexity.

If this is your thing, you might also enjoy our pattern on Decoupling. 😀