There is a big difference between what it means to become obsolete today compared to what it meant 10+ years ago. 10+ years ago, most of the new software trends made sense. They served a purpose. JavaScript and front end frameworks became popular because internet use was booming. NoSQL databases like MongoDB became popular because they allowed startups to scale more quickly and combine data from multiple sources more flexibly. Docker became popular because it allowed people to deploy services more quickly and fit nicely with microservices architecture which also helped with scalability.
On the other hand, more recent trends don’t make much sense. For example, in a way, TypeScript takes us backwards. Most junior devs don’t realize that interpreted languages were once considered a major innovation… With TypeScript, we’re adding back the build step which was considered a major problem only a decade earlier… We’ve completely forgotten the benefits of interpreted languages in terms of significantly speeding up the dev/test iteration speed. Instead, we’ve allowed bundling (which used to be restricted to production environments) to take over our development environments too (and slow us down further). This slow-down in iteration speed due to the bulky build step adds up and, more importantly, waiting for the build breaks developers’ focus (which is particularly harmful when coding; you don’t want to lose your train of thought and forget to do something important).
I remember clearly, a decade ago, when senior Google engineers were discussing some of the optimizations that they had made to v8 to achieve similar execution speeds as compiled languages. That was considered a major feat of engineering back then. Nobody wanted to wait for a build step because it slowed down the development iteration speed. It was a major pain and v8 gave us the best of both worlds.
So why then nowadays are all developers so keen to go back to development approaches which we had been trying to get away from just a decade earlier? Nobody can give any good reason.
Another problem which is common nowadays is dependency bloat. I could foresee this issue coming years earlier. Most projects have thousands of tiny dependencies and sub-dependencies. This is a constant source of vulnerabilities and compatibility issues as these dependencies are poorly maintained. Developers nowadays don’t pause to think for a second when introducing new dependencies into a project… They assume that the cost is 0. This attitude is extremely harmful to a project.
Another issue is the monorepo trend… If developers knew how to separate concerns properly and designed their components as blackboxes, they wouldn’t need all their components to be tightly intertwined to the point that they couldn’t be updated independently. In the ‘old’ days, developers took the idea of “high cohesion, loose coupling” very seriously. Nowadays components are so poorly designed and so tightly coupled to each other that it’s impossible to use a multi-repo approach because changing one component usually requires changing a different component in a completely different part of the code… Monorepo is not a solution for poor design, it’s a bandage patch which hides the problem.
Anyway I could discuss for hours all the things that have gone wrong over the past few years and I can back up all my statements with proof of how avoiding these modern anti-patterns allowed me and my collaborators to build efficient, maintainable and scalable systems in record time.
These days, talented, critical-thinking developers are becoming obsolete. The industry no longer cares about building things quickly, efficiently and in a maintainable way. The goal today is not to build great products. It’s merely about job creation.
