To benefit from abstractions, you need to understand them first. We engage in acts of designing and executing abstractions all the time without realizing it. While the human mind is often involved in implicit abstractions, in this essay, we are particularly interested in explicit abstractions.
More specifically, we are interested in explicit abstractions that help us solve real-life day-to-day problems with a sense of agency and efficiency that we can tangibly appreciate. A great source of inspiration for designing abstractions is the world of computer science.
It is no coincidence that this essay is the fourth entry in the series: how to benefit from computer science in real life. We will begin by covering what an abstraction is. Then, we will get an intuition for designing abstractions using an illustrated example. Finally, we will dive into more advanced concepts such as layers of abstraction and cost of abstraction.
At the end of this essay, you should be able to intuitively think in terms of abstractions and gain exposure to the fundamentals of designing useful abstractions that solve real-world problems efficiently. Without any further ado, let us begin.
This essay is supported by Generatebg
What is an Abstraction?
An abstraction is a method/technique that manages the complexity of a system. Let us say you have a complex system at hand. Using an abstraction, you can hide certain complex parts of the system in such a way that the organized system is simpler to use for the end-user.
So, one of the primary goals of abstractions is to make complex systems approachable and easier to understand. A good example of a useful abstraction is a coffee machine.
A coffee machine contains a lot of internal components and subsystems that are beyond the technical ability of its average user. But the designers of the said coffee machine manage to organize these parts as abstractions such that the end-user treats the machine as a black box.
When you or I use a coffee machine, all that we care about are the inputs (milk, sugar, coffee beans, etc.) and the output (coffee). To us, the internal subsystems are irrelevant. This is what a good abstraction achieves; it makes a complex system more approachable.
However, abstractions go beyond just household appliances. They can be applied to any complex system. To deepen our intuition around this concept, let us consider the complex framework of human systems.
How Do Human Systems Benefit from Abstractions?
You may not have thought about it in this manner, but a good example of a complex human system is any human organization. Suppose that you are the Chief Executive Officer (CEO) of a tech company. Your organization is split into the âtechâ department, the âbusinessâ department, and the âcustomer serviceâ department as shown in the below illustration:
As you can see, the department leads from âtechâ, âbusinessâ, and âcustomer supportâ report directly to you, while they hand their own departments. This in itself is an abstraction to make the complex human system more approachable. A cruder system would be that you yourself (as the CEO) micromanage tech, business, and customer support (without line management).
This is indeed possible, but things could get out of hand really fast. You would not like to be the bottleneck for your own organisationâs productivity now, would you?
You see, what an ideal abstraction enables us to do is split the complex system into clearly understandable parts that feature more-or-less well-defined tasks. In your organisationâs case, splitting the functions of tech development, business affairs, and customer support enables smoother and more efficient functioning of employees as everyone is aware of who is responsible for what.
But before we celebrate your organisationâs efficiency, we need to look at the bigger picture. We are just looking at one layer of abstraction. When we look at multiple layers of abstraction, splitting functions may not always be the best solution.
Layers of Abstraction in a Human Organisation
One fine day, your chief of tech comes to your office, complaining that he is confused. As you listen to his complaint, you understand that at there is significant overlap between different departments at the second layer of abstraction (floor-level).
This overlap is leading to confusion between the department leads as to who is taking care of what. Below, you can see an illustration of the issue that you are facing here:
The âbug fixersâ are currently shared between âtechâ and âcustomer supportâ, whereas âcustomer channelsâ are shared between âbusinessâ and âcustomer supportâ. You will need to handle this situation right away before the issue escalates and affects productivity.
Issues with Layers of Abstraction in a Human Organisation
One solution to the problem could be to split âbug fixersâ into two sub-departments: one for âtechâ and one for âcustomer supportâ. Similarly, there could be two âcustomer channelsâ, one for âbusinessâ and one for âcustomer supportâ.
Another alternative could be to merge or move sub-departments. For instance, âbug fixersâ could be removed from âtechâ and integrated exclusively into âcustomer supportâ. Similarly, âcustomer channelsâ could be removed from âbusinessâ and integrated exclusively into âcustomer supportâ.
The bottom line is that splitting/combining sub-departments almost always comes with drawbacks. Not all combinations of splitting/combining are good. But some are better than others. We will eventually get to how you could work out better solutions.
For now, the takeaway is that even though layers of abstraction come with drawbacks, it might be worthwhile to explore them because in the end, they make our lives easier.
How Do Computers Benefit from Abstractions?
In order to solve your organizational issues, we could take inspiration from the world of computers. You see, when AMD or Intel releases a new processor, the manufacturer also publishes an abstraction layer called âassembly instructionsâ or âmachine instructionsâ along with the processor. These instructions are essentially the language that the processor understands.
It is very difficult for human beings to work with the machine language. So, what we ended up doing is create another layer of abstraction that is closer to our own language(s). This is what is typically known as a programming language (like C, Python, etc.). Once you write a set of instructions as a computer program, something known as an âinterpreterâ converts this to machine language for the processor.
Now, all this conversion and interpretation takes time. That is, these layers of abstraction come at a cost, which is known as the cost of abstraction. However, they make the overall process smoother and easily approachable. It is technically possible to solve problems by writing machine code, but it is akin to the CEO micromanaging all of the functions without any department leads.
Now that we have covered how computers benefit from abstractions, let us see how we choose between different abstractions by computing the cost of abstraction.
How to Compute Cost of Abstraction (resource trade-off decision)?
Suppose that you have written a Python program to solve an issue in your organization. This program runs for 90 seconds on your computer and costs 2 cents per hour of run-time. If you were to run this program 500 times, you could compute the total cost incurred as follows:
So, running the program 500 times would set you back by 25 cents. This is literally the cost of your current abstraction. Let us now say that one of your top tech employees has come up with a better program that she wrote in the assembly language. Her program runs in 10 seconds.
However, implementing her program would take 1 hour of her time, which would set you back by $100 (her wage amounts to $100 an hour). The question now is:
Given the cost of implementation of $100 and improvement in the runtime of 80 seconds, is it worth implementing the new program in assembly language?
To answer this question, let us calculate the number of runs that would be required with the new program to offset the cost of paying your developer an hourâs wage to implement it:
So, you will need to run the program at least 225,000 times to offset the cost of implementing it. The answer then is âIt depends!â
It depends on whether your organization requires this particular program to run often enough. Suppose the program is expected to run well more than half a million times, it makes sense to bear the cost of implementing the assembly language version.
Now that we have solved the issue for the computer program, let us get back to your organizational chart.
How Can Your Organisation Benefit from Abstractions?
What we essentially did with the computer program problem is to compute the solution to a resource trade-off problem involving costs of different abstractions. Similarly, in the case of your organization, it makes sense to first simulate different combinations of departments and sub-departments in terms of cost of abstraction and speed/efficiency of global function.
Based on the simulations, you could choose to try out a few options before you settle down on the best practical solution that leads to the best productivity whilst sustaining the easiest approachability for all parties involved.
Final Remarks
We have already seen that designing and implementing abstractions comes at a cost. Like with the example involving the programming language and the assembly language, whenever we have different parts interfacing, we are essentially slowing down performance by introducing more communication. So, abstractions are likely to (not always though) slow down operations.
However, in most cases, the cost of abstraction is well worth it because abstractions help us not only approach complex systems more easily, but they also enable us to maintain and repair systems more easily/swiftly in case of errors or malfunction!
If youâd like to get notified when interesting content gets published here, consider subscribing.
Further reading that might interest you: Why Are Analogue Computers Really On The Rise Again? and How To Benefit From Computer Science In Real Life (I)?
If you would like to support me as an author, consider contributing on Patreon.
Comments