Theory of Abstraction

I’ve been building software for years, what I love about it and sometimes hate is that everything keeps changing so fast that a framework can become obsolete and deprecated within two years or even less.

What happens is that a lot of projects don’t want to reinvent the wheel, which makes a lot of sense. They use external libraries and frameworks. These external dependencies are strongly coupled inside the project.

Which makes it hard and sometimes impossible to replace or update. And guess what, these dependencies introduce vulnerabilities and security issues, or sometimes they use an outdated approach and do not follow the latest trends, which makes them no longer optimal to use.

So the more you rely on external dependencies, the more you are likely to have to refactor many parts of your application, or even worse, replace the entire thing. This can be very costly, and not only that, since there is a pandemic of low-quality code and documentation, the process of modernizing your app will be very difficult and hard to do.

So, Mr. Amr, what will we do? How can we do software development and develop software that can run forever? When the aliens come down and they try to run it, it will be as easy as calling an npm script.

There is no simple answer, but there is an approach that I'm adapting currently that we think can mitigate these issues. Although,
Eventually, you will reach a point where you will have to refactor the entire thing; this will make the process easier and even a breeze.

The Theory of Abstraction State:

The more Abstraction you introduce inside your code, the more likely you are to replace and update dependencies inside your code.

No easy way to do this, and the level of abstraction can vary a lot between projects. For example, if you are using Angular and you have one of the well-known
packages such as PrimeNG, where you will use a modal. You can use it directly from the library, but what will you do if you want to update or even replace the entire library?

Using any external dependencies as a very tightly coupled unit inside the code will make it a dependency hard to replace or change. I'm sure the good folks at PrimeNG will maintain the computability as much as possible. But, since technology changes at an insane rate, they have to do a cut-off support at some point, like any project that wants to stay relevant.

I worked on a very large project that used Angular, and when I wanted to update it the version I hit a wall with a package that was used all over the place. And its job was only to display a Model! So, it was difficult to update.

It was very difficult to locate its usage and where to update. Since then, I thought, what if I introduced just a small component that holds any modal library, and instead used it? Then my update was way simpler.

Also, many open-source packages start with a free license and then switch their license, which can lead to many implications. By adding an abstraction layer (I know it's a difficult task) to all or at least the most critical package(s), it can lower the update and change time.

Remember that the framework version is just a number, code never rusts and will not be a big issue to use even .NET 4.5 or Angular 7 to this day, unless there is a critical security issue or you can no longer run the application.

Originally published on my blog