We have used too many abstractions and the future looks bleak.

We have used too many abstractions and the future looks bleak.

A large percentage of so-called “experts” today only know how to use some hype tool, but they don’t understand anything about how things work on a deeper level. This is a real challenge and a big problem for the future.

A steering wheel is an abstraction that makes driving a car easier. Power steering is another level of abstraction that enhances the driving experience. Abstractions are good, they usually increase the quality of life. However, we have a proverb in Denmark that says:

“Too little” and “too much” will spoil everything.

What good is an abstraction when it breaks down and no one understands how the underlying technology works anymore?

Too much of the IT industry is focused on making a profit and too little on everything else. You need to be able to release new products or new services faster and faster. And that means even more abstractions and more automation, fewer and fewer people and less deep understanding.

Today, “programmers” and “system administrators” practically do not exist, instead we now have DevOps and even DevSecOps positions, in which the industry tries very hard to cram all possible tasks into one person. Technical specialists should be involved in both development (Dev), security (Sec), and operations (Ops), i.e. system administration. But since no one person can really master it all, everything has to be automated as much as possible to save money and avoid the complexities of human interaction between different departments. As a result, today’s technical professional is only taught how to use specific tools, but then he or she gains very little knowledge of the technology behind those tools.

The fact that technology is becoming more and more difficult to understand, and more and more of modern life depends on the technologies we use, is not at all relevant. So what happens when the level of understanding in the tech industry reaches such a low point that most people don’t even know how to fix the tools they use?

People are used to so many abstractions and they think this is the right approach, and they happily contribute to this mess by adding more abstractions.

Yes, yes, let’s code everything in assembly again!

— a sarcastic comment from a proud developer

We need abstractions, no doubt, but each level of abstraction has to be paid for, which ironically can ultimately lead to a huge loss of revenue.

Already, most “security experts” know very little about their own security, and only know how to use some ready-made pentest tool. The pentest tool shows a bunch of green lights in its web interface, and everything is supposed to be fine. Nevertheless, real a security expert with malicious intent hacked the system a long time ago and has been selling valuable data on the darknet all this time. Nothing leaks and nothing is revealed. This can go on for years and no one will know, well, because the GUI says 🟢All in order.

One simple example

One company I helped with security used a third-party contractor firm that hired exactly these people. The developers knew how to build a site and API using a “modern framework” but understood little about the framework itself and absolutely nothing about security. And as soon as problems started, no one could figure out what was going on. In fact, they struggled with this situation for several months before finally deciding to seek help.

One look at how poorly everything worked was enough to understand that something was wrong. I copied everything for offline testing and first started looking at the code of this system. I spent the evening going through lines of code, file by file, comparing the original framework files to those running on the company’s host machines. Just by looking at the code and files.

Of course, it wasn’t my intention to review everything in a row, but it’s often surprising how much you can learn from a little manual review. Often the truth lies right on the surface, and with a little patience you can find it. This, of course, requires more than a basic understanding of how the technology works. Some students today probably don’t even know what files and folders are?

Long story short, in this case it turned out that they were hacked and the system was being used as a kind of backend to distribute porn and other junk. The performance problems were not caused by the hack, but by the framework itself, which was very slow (nothing surprising in this, but that’s another story). The hack was pretty stealthy and most likely would never have been discovered if I hadn’t decided to “poke around” and actually look at the files and code.

NOTE

I’m deliberately not going into the details of this case with code examples etc., as that would require a separate post, clearly dedicated to security (and possibly specific performance issues), which is not the topic of this post.

Tips for those studying technology

  • Never just follow hype or trends;

  • Be curious. Don’t just learn the tools, try to understand how the underlying technology works;

  • If possible, try at least once to manually do what the tool does for you;

  • If possible, try to view the tool code. Even a basic understanding of code can be very valuable;

  • Stay curious. Keep learning. Experiment. Dive deeper into the technology that interests you. If possible, create a home lab and use it as a training and improvement platform;

  • Question everything. Especially what seems to make no sense. Don’t just assume that someone else knows better – you quickly turn into a blind follower. Sometimes someone else really does know better, but don’t just assume that’s the way it is. And be brave! Stand up for the truth and your beliefs, even if it makes you feel alone.

PS:

What I’m trying to say in this post is not that everyone should understand everything from scratch or that you shouldn’t use any tools. As I said, we need abstractions. In addition, we have people who specialize in different areas, for example, a mechanic repairs a truck and a driver drives it.

Rather, I’m talking about that how important is the engineering approach to technology by the people who work with the technology.

For example, in software development, too many specialists have been abstracted and replaced by tools and automation, and fewer and fewer people understand anything even one level below the level they work at.

This is a serious problem because eventually we will reach a point where very few people can fix anything at the lower levels. And the fact is that we have already partially reached this point!

About six months ago, I came across some web developers who didn’t know that you can build a website without a deployment tool and that you don’t need JavaScript at all, even when the website accepts payment. I asked a friend of mine who was teaching a Python class at the time about this and he said:

Don’t be surprised by this. This is today’s level. The industry wants us to churn out people who know how to “push buttons”, not people who understand things on a deeper level. They are more or less interested only in quick implementation.

I know there will always be people interested in lower level software development, but not in this one. The thing is, in software development itself, we’ve long since reached a point where we’ve added too many layers of abstraction and too few people understand what they’re doing. Industry is shooting itself in the foot.

If, for example, I’m a web developer, whether front-end or back-end, or doing so-called “integration work”, and I build websites without much coding or any knowledge of TCP/IP, DNS, HTTP , TLS, security, etc. using only off-the-shelf tools or frameworks will make me about as useful as a monkey with a torque wrench when things go wrong.

Related posts