An abstraction is worth a thousand words

The power of abstraction is vast. The human brain can only process information in chunks. When you explore something mentally, each tiny bit of detail adds on cognitive load.

Example: A House

When we talk about a house, we actually mean a rich, complicated construction containing walls, windows, doors, a roof and many other “building blocks” that we may not even be familiar with.

NOTE #1:

This is the power of abstraction; abstraction is a tool. It enables us to speak about something (a concept, a thing, a process, etc) without even knowing its inner workings, yet being able to understand what it is and how it is used.

NOTE #2:

Abstraction can recur to infinity. In our example, we broke a house down to some “building blocks”; a wall, window, door, roof, etc. But what exactly is a wall? A roof? What about a door? Are these constituent units atomic? Of course not! Those are abstractions, too, that can be further broken down in more abstractions (a set of bricks, glass, a lock, etc) which in turn can be broken down, recurring on and on and on…

Let’s look at the house from the constructor’s point of view, and zoom in on the very specific task of placing the building’s door. Also, let’s suppose that abstractions are not used in the communication of the construction team. How would the organizer of the team assign them with the said task? He would be compelled to describe the “door unit” thoroughly, covering all possible levels of detail, wasting precious time and confusing the workers with information that is not needed.

If this was the only way to communicate and instrument heavy tasks, very few would have been completed in all history of mankind!

The construction team does not even need to know how a door is made, how a lock is made or how it works.

This results in…


And this is exactly the mistake that many of us do when crafting software. We structure the code in a way that implementation details are coupled with the top level view of the architecture, thus disabling anyone who reads it or maintains it from interacting with the system at a minimal level of complexity.

Breaking a design concept down to abstractions helps us organize our thoughts better, remember a wider span of the overall architecture and thus write better quality code.

That’s why we should always strive for modularised code with high class coherency. This code is easier to reason about.

The very nature of programming, the fact that the products created are not tangible and that one affords to perform infinite “undos” during construction without the fear of wasting materials, conduces to many software engineers falling to the same pitfall; we take our craft lightheartedly and always think of a software project as something simple, uncomplicated and pretty straightforward, although software creation IS analogous to complex building construction.

The fact is that code can be straightforward even for large scale projects, but only if it has been built with respect to the way the human mind operates. That is, structuring it in a way that minimizes cognitive load, offering the reader the ability to work on it in various levels of detail according to his needs, and resulting in a top-level view that consists only of familiar concepts.

For example, taking a look at the code of a program that reads data from a socket and outputs it to the screen, should not overflow your mind with implementation details of the communications with the socket or the underlying hardware. The top-level view should only inform the reader of two things; the fact that the program reads from the socket and the fact that it prints to the screen. Should the reader want to learn more about the inner workings, he would then view the code of the respective classes/methods that are used for each task.

As an epilogue, let’s get back to the title of this article.

An abstraction is worth a thousand words

Let’s see it by example:

Here is a picture of a green valley. But one does not see just a valley. A cloudy sky enriches the view with the formations the clouds create. The observer will also notice the variations of the color of the grass, the morphology of the ground creating a bumpy terrain, the few dispersed trees and perhaps many other stuff. That’s why a picture is worth a thousand words. Because the human mind is trained to treat a picture as a set of abstractions, and focus at many different levels of detail.

We are able to observe a top-level overview of it (a green valley under a cloudy sky), noticing some core components that we are already familiar with and enjoy the resulting view. But as we zoom in on the various parts, each component of the picture gets broken down in more detail giving us the opportunity to explore things that did not draw our attention at first sight, but are nonetheless essential for the end result.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Containerizing a Python app — MySQL + Python + Docker

[NSO Guide] Cisco Network Services Orchestrator |

Target-typed ‘new’ expressions in C# 9

Hobby Projects ft. Rachit Gulati | Season 1 Episode 2

Udacity data-engineering nanodegree 2019

Tekion Corp Interview Experience- Selected

Visual density and it’s problems

The most valuable tip towards writing highly legible code

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


More from Medium

Weekly Digest #67

Spend your time in Code Reviews, not in writing Tests

One Thing I Wished I Knew Before Making Merge Requests

Writing tests after release is a mistake