Low abstraction technologies such as go and typescript - 7 ways to ... Part5

Part 5: Low abstraction technologies (Go, Javascript)

Technology choices based on abstraction level are pretty easy.
You follow one simple rule: choose the highest possible abstraction that will still give you just enough flexibility over the result to reach your goal.

This is something people naturally understand. If you can use no-code to build a prototype for a presentation, why bother writing code?
If low-code is sufficient for your MVP, why hire a lot of developers to write something from scratch.
If, as a developer, you can choose something that solves your use-case with less code, use it.

This way of making choices will result in higher productivity. Less code also means less defects and higher reliability.

Being able to achieve a goal with 20 lines of code is better than achieving it with 2000 lines of code.

Who would argue that?

Actually and surprisingly, a lot of people do. And the industry trends undergo cycles.

In the 1990ies, you could write, let’s say, Delphi code, by dragging and dropping network sockets and UI elements, double-clicking them to then hook (little) custom code to events.
The result was a self-contained binary, namely an .exe file that included everything needed to run an application.

Shortly after, Java hit the scene and it brought massive complexity. I remember FactoryBuilderFactories, versionised external configuration, patched JVMs and more darkness.
Java applications were hard to understand, hard to build, hard to deploy, hard to configure and hard to manage in production.
Let’s not even start discussing web-frontend development at that time. If you have never suffered from jquery-heavy websites with the lack of testability and mixture of style, structure and functionality, you have not suffered in frontend development.

Around the 2010s, there was a massive trend towards higher abstraction. In backend, you could create a self-contained jar-file including a Java Application, all configuration and even the runtime environment including the servlet container.

In frontend development, angularjs came up. And it made me enjoy frontend development for the first time. You could just add a tag to your html, angularjs would be downloaded from a cdn and immediately work.

While I still consider this low abstraction in comparison to the might of server-side-frameworks that produce browser-consumable code from proper programming languages and frameworks (mostly in a terrible way, unfortunately), in a lot of scenarios angularjs was great to use. And relatively simple, too.

What happened next can only be explained through the fact that developers seemingly got bored. Backend developers killed their newly improved productivity with unnecessary complexity in code and infrastructure modularization. Frontend developers invented progressive web apps and a lot of other madness, overcomplicating frontend applications as well as their build and assembly-requirements.

If I look at react and angular today, I do not know where to hide between way-too-low abstraction and complexity overkill.

But as an industry, we did not stop here. We found reasons to write code in low abstraction technologies such as go. Or Javascript, both in frontend and backend (and don’t be fooled: while Typescript improves the language, it does not add all the other important aspects of a healthy programming and runtime environment for applications).

Old people know the KISS principle.
Keep it simple (and) stupid.

It came from aircraft engineering and it spread across all other disciplines of engineering including software engineering.

A good engineer choses to simplify everything. A good engineer does not opt for avoidable complexity because something is fancy.

A good engineer wants to be in control of his code.
Control comes from oversight.
Oversight comes from abstraction.

If you did avoid high abstraction technologies without a good reason for it, you and your peers are writing and maintaining a lot of code you should have never written.

This keeps you from delivering real value.
And this way, you are burning company cash every day.

How do you feel about the choice of ecosystems and abstraction levels that come with them? Do you also feel the value-add of being able to control every aspect of your application is not worth the loss of the support of enterprise technologies?
I am looking forward to your comments!

If you missed the other parts of this series, go read and discuss them as well:

Part 1 – Trends
Part 2 – Microservices
Part 3 – Docker + Kubernetes
Part 4 – Kafka
Part 6 – Using Slack for Monitoring
Part 7 – Cross-Team Collaboration