, ,

The Abstraction Problem – A Great Evil

There is a great evil Spirit that is haunting the streets of code in the land of programmers. It’s a Spirit of obfuscation and twisting things into what they are not. The Spirit wanders around on the loose looking for someone, and it finds ready victims among the ranks of new programmers and the innocent young minds in University. It also finds a few old wizened souls that have been lost wandering for decades around the halls of some musty Fortune 500 company.

It’s the Abstraction Problem.

I will be more specific later about the evils of OOP, of which I have come to abhor in most cases, but I digress. The real problem is the Abstraction(s).

A Funny Thing

I find it interesting and funny that you will find very few programmers who argue about some popular concepts …

  • KISS (Keep It Simple Stupid)
  • Separation of Concerns
  • Evils of Side Effects
  • DRY (Don’t Repeat Yourself)
  • Law of Demeter
  • etc.

Now go ahead and ask yourself a question, especially all you code writers with experience … what is really the point of all these laws to which we are supposed to submit ourselves?

They are protection really. They are universal truths that have been accepted by the masses as legitimate over the eons that our collective bloody fingers have been smashing out bugs until our keyboards crack and fail. They are a collective mind if you will, that has seen the slippery slope of complexity creep up and destroy all that is good.

Simplicity. We strive for simplicity in the code we write.

  • We want easy maintenance.
  • We want easy debugging
  • We want easy feature additions

Then comes the Evil Abstraction Spirit.

I don’t know how it exactly happens, although I have an idea. Much of the Abstraction Problem comes in the form of misused OOP (Object Oriented Programming). I was captured by the same wayward Spirit myself when I was a young gun. I was enamored. I loved the way the code flew off my fingertips.

I learned. I read. I learned more. Inevitably through some medium with meet with OOP. We learn about Classes and inheritance, it’s like a whole new world. OOP is a valid way to design and solve problems.

But, in our zealous ways, we overdo it and get stuck in our ways. It’s sticky, it follows us.

STOP IT!

Not everything needs to be abstracted! Like seriously. Just learn to use tools and packages. You don’t need to abstract everything. Make people work for it. Sure, there are a lot of specific business problems that are a perfect fit for OOP, and I’m fine with it. I use Classes and Inheritance a lot around certain utility programs I have written, but the use case is very specific.

But for the love of all that is good, stop abstracting obvious things and making things complicated that should be that hard!

Here are things Data Engineers especially should stop abstracting.

  • Working with cloud storage like s3 with tools like boto3
  • Random data transformations
  • Docker and other command line tools
  • Bash
  • Anything SQL related

There is normal programming using a myriad of tools. Stop abstracting them. At the very least abandon OOP for the problems. It’s dumb and add complexity and un-needed abstraction.

I’m fine if you have super-specific Business Logic and problems that require more complex solutions and warrant Abstraction in the form of OOP (multiple inheritance etc).

Examples of this Great Evil.

Here, at least you don’t know what I mean, let me show you from my own life and code.

5 years ago in the Year Of Our Lord 2019 I wrote pyGutenberg which was a Python wrapper to be able to download and work with flat-files of Books from Project Gutenberg.

Doing some simple work really only required very basic sets of Python packages.

Of course, in classic fashion I made the code way more obtuse than I needed to.

I mean this is sort of a play example and real Production examples are much more egregious, but I still think you can generally see the problem.

The class is pointless. There is no reason for its existence.

All it does is make …

  • Following calls to self more tedious
  • Following arguments through the codebase harder
  • Simply making the code an eyesore to look through
  • Harder to debug

Of course in real production situations, this can become a serious issue. Every single time we layer on an unnecessary abstraction we add pain and suffering to all those coming after us.

Let’s all shake our collective hands and make a promise to ourselves. Stop abstracting what does not need to be abstracted. Give the future readers of your code the benefit of the doubt, they are smart and don’t need your help. Stop reaching for the same tools and the same solutions (and abstractions) for every single problem over and over again.