What is an Abstraction?

An abstraction is a strategy or method for managing the complexity inherent in a system. Imagine dealing with a complicated system; abstractions allow you to conceal certain intricate components, making the overall system simpler for the end user.

One of the primary aims of abstractions is to render complex systems more accessible and comprehensible. A classic example of an effective abstraction is a coffee machine.

A coffee machine is comprised of numerous internal parts and subsystems that are often beyond the grasp of the average user. Nevertheless, its designers have organized these components in such a way that the user perceives the machine as a straightforward black box.

When using a coffee machine, our primary concerns are the inputs (like milk, sugar, and coffee beans) and the output (the coffee). The inner workings are of no concern to us. This is the essence of a successful abstraction—it simplifies a complex system.

Yet, abstractions extend beyond home appliances; they can be applied to any intricate system. To deepen our understanding, let’s examine how abstractions function within human systems.

How Do Human Systems Benefit from Abstractions?

You may not have considered it this way, but a prime example of a complex human system is any organization. Suppose you are the CEO of a tech firm. Your company is divided into the ‘tech’, ‘business’, and ‘customer service’ departments, as illustrated below:

In this structure, the heads of the ‘tech’, ‘business’, and ‘customer support’ departments report directly to you while managing their respective teams. This arrangement serves as an abstraction that simplifies the complex human system. A less effective model would involve you micromanaging every aspect of tech, business, and customer support.

Such micromanagement is indeed feasible, but it could quickly lead to chaos. You certainly wouldn’t want to be the bottleneck stifling your organization’s productivity.

An effective abstraction allows us to divide a complex system into comprehensible parts, each with relatively clear responsibilities. In the context of your organization, separating the functions of tech development, business operations, and customer support fosters smoother and more efficient employee performance, as everyone knows their specific roles.

However, before we applaud your organization’s efficiency, it’s important to consider the broader picture. We are examining just one layer of abstraction. When we analyze multiple layers, splitting functions may not always yield the best results.

Layers of Abstraction in a Human Organisation

One day, your chief of tech approaches you with a concern about confusion arising from significant overlaps between departments at the second layer of abstraction (the floor level).

This overlap is causing uncertainty among department heads regarding their responsibilities. Below is an illustration of the challenge at hand:

Currently, the ‘bug fixers’ are shared between the ‘tech’ and ‘customer support’ departments, while ‘customer channels’ are shared by ‘business’ and ‘customer support’. This situation needs immediate attention to prevent further complications affecting productivity.

Issues with Layers of Abstraction in a Human Organisation

One possible solution could involve creating distinct sub-departments for ‘bug fixers’—one for ‘tech’ and another for ‘customer support’. Alternatively, you might choose to merge or relocate sub-departments; for instance, integrating ‘bug fixers’ solely into ‘customer support’, and removing ‘customer channels’ from ‘business’ to make them exclusive to ‘customer support’.

Ultimately, splitting or combining sub-departments can present challenges. Not every combination will yield positive results, but some arrangements are more advantageous than others. We’ll later discuss ways to identify the optimal solutions.

For now, remember that while layers of abstraction have their drawbacks, exploring them can often be worthwhile, as they simplify our lives.

How Do Computers Benefit from Abstractions?

To address your organizational issues, we can draw insights from the realm of computers. For instance, when AMD or Intel releases a new processor, they also provide an abstraction layer known as “assembly instructions” or “machine instructions.” These serve as the language that the processor understands.

Working directly with machine language is challenging for humans. To bridge this gap, we’ve developed another layer of abstraction that aligns more closely with our languages—programming languages like C or Python. When you write a program in these languages, an “interpreter” translates it into machine language for the processor.

However, this conversion process takes time, meaning that these layers of abstraction incur a cost, commonly referred to as the cost of abstraction. Despite this, they streamline processes and enhance approachability. While it’s technically feasible to solve problems using machine code, it resembles a CEO micromanaging all functions without department heads.

Now that we’ve examined how computers leverage abstractions, let’s discuss how to select between different abstractions by assessing the cost of abstraction.

How to Compute Cost of Abstraction (resource trade-off decision)?

Imagine you’ve developed a Python program to address an issue within your organization. This program runs for 90 seconds and costs 2 cents per hour. If you execute this program 500 times, you can determine the total incurred cost as follows:

Thus, executing the program 500 times would amount to 25 cents—the cost of your current abstraction. Now, suppose one of your top tech employees devises a more efficient program written in assembly language that runs in just 10 seconds.

However, implementing her solution would require 1 hour of her time, costing $100 (her hourly wage). The question arises:

> Given the implementation cost of $100 and an 80-second improvement in runtime, is it worth transitioning to the new assembly language program?

To answer this, let’s calculate how many runs of the new program would be necessary to justify the cost of paying your developer for an hour:

To offset the implementation cost, you would need to run the program at least 225,000 times. Therefore, the answer is “It depends!”

The decision hinges on whether your organization will require this specific program to run frequently. If it’s anticipated to run over half a million times, then adopting the assembly language version is a sensible investment.

Now that we’ve resolved the issue concerning the computer program, let’s return to your organizational structure.

How Can Your Organisation Benefit from Abstractions?

What we essentially tackled with the computer program scenario was a resource trade-off problem concerning the costs of different abstractions. Similarly, for your organization, it would be prudent to simulate various combinations of departments and sub-departments, assessing their abstraction costs alongside their efficiency.

From these simulations, you could experiment with several configurations before identifying the most practical solution that maximizes productivity while ensuring ease of approach for all involved.

Final Remarks

We’ve established that designing and implementing abstractions entails costs. As illustrated in the programming language versus assembly language example, introducing different interfaces can often slow down performance due to increased communication overhead. Hence, abstractions may sometimes hinder operations.

Nonetheless, in most cases, the benefits of abstraction outweigh the costs, as they not only simplify our engagement with complex systems but also facilitate easier maintenance and troubleshooting in the event of errors or malfunctions.

For further reading that might pique your interest, consider Why Are Analogue Computers Really On The Rise Again? and How To Benefit From Computer Science In Real Life (I)?

If you wish to support my work as an author, please consider contributing on Patreon.