Abstraction empowers learning, but can also empower a lack of meaning
Is abstraction always a good thing? In my early days of programming I thought so. When learning I thought so. It is how we can grow, right? I have started to question the balance of abstraction more and more recently, across software and programming, and beyond.
My abstraction in programming journey
Kent Beck said it well:
“First you learn the value of abstraction, then you learn the cost of abstraction, then you’re ready to engineer.”
In my early programming days I thought a lot about data and algorithms. Then I started programming Java and I got too obsessed with OO design and abstractions. The gang of four and all of those pattern books. Pattern matching is good…. so patterns are good! Of course, when I would go beyond the high level conversation I found that one of the most important pieces of information about the patterns was the “context” piece. I keep finding that context is king when it comes to pattern matching!
From spaghetti code to rotini code
We have all seen how bad spaghetti code and architecture. Thousands of lines of brittleness, crippling connections between components, bringing your application development to a crawl. For awhile it was en vogue to use objects as the True Way to get modularization. You end up with solutions such as OSGI. Incredibly modular, but to many people it can be taken too far.
The new Android Studio is using IntelliJ, which made me happy since I was always an IDEA over Eclipse guy. One of the reasons in the Google IO session for the switch was that the Android dev tools team was finding it too hard to get done what they needed too. This is a sad thing to see since Eclipse is meant to be a platform for building tools! I remember meeting with some of the founding members of the Eclipse project and how they felt like they built the framework but then it all shipped…. before it was truly packaged together.
The problem with hyper abstraction is that there are tons of small components that barely do anything and you can’t easily see how they work together. Zooming between the forest and the trees is incredibly hard. For every piece of business logic you are fighting with interfaces and abstract classes and configuration files and then FINALLY you get to some actual code that does something. Have you ever seen this code? It feels more like Rotini than Spaghetti, but in some ways it is even harder to understand.
When you have a hammer everything looks like a nail. When you are first armed with some patterns and libraries the same can happen. You try to work out which abstraction to put on the problem and it is hard to be mindful of what the actual problem is and spend too much time on implementation details.
So, too much abstraction can be bad, and the art is in knowing where not to abstract (as Kent said).
Abstraction and Language
You can take this further into language itself. As soon as you name something you create a new abstraction. These become building blocks and when used wisely allows you to go up the stack and get new learning and understanding. The danger of having these names is that they can quickly join your subconscious and you may stop understanding the “why” and “how”.
For example, a friend was talking to me about the notion of condensation. I learned about it in some science class, but once I had a name for it I moved on. At this point I have forgotten how it actually works. How does water get on the other side of the glass again? I no longer question it, I couldn’t talk to how it would be different if you changed water with wine, or switched the glass bottle to plastic. I have lost the understanding of the concept and am left with the name and move on. I think this can be so very dangerous, especially when you see it stack together with chains of information.
The notion of the “waterfall” methodology came from a misunderstanding. A paper on the flaws of waterfall was not understood, and someone took the EXACT OPPOSITE message and talked about how it was a good thing. Fast forward and this flaw grows and grows and boom. A large part of the industry ends up running in the wrong direction.
There is a constant balance and tension, and you need to be able to jump up and down the stack. The more I experiment, the more I am mindful on which level of abstraction makes sense for my problem at hand, and I remember to jump down the stack regularly so I don’t lose sight of the context.
I no longer climb up and up and up, but enjoy a balanced journey in my path through abstraction.