From hype-based to rational Software Architecture

Introduction

If you've been on the internet the past 2 years, at least on the technical side of the internet, you've probably seen the amount of hype going around the IT/software industry.

About a year ago, those "three-letters images" that I shall not repeat were all the rage. Every company was trying to get on the bandwagon, they all wanted to get a piece of the pie. Then, as it was bound to happen, the hype died down. Those fake currencies died, a lot of money was lost to hackers/scammers/etc., and finally, companies stopped pursuing that. I'm one of those people that were always skeptical that any of that was ever done in good faith.

But if you look at the industry now, you'll see that the hype is still there, it just moved to a different topic. The new topic? You guessed it, AI/ML/LLMs. You can easily see how GPT and similar LLMs are all the rage and everyone wants to do everything with them. Has anyone stopped to think about the implications of that?
Especially the legal ones? The class-action lawsuit against Microsoft's GitHub's Copilot suggests there are a great deal of things that are yet to be defined. And the number of 'products' being built that are just a wrapper around ChatGPT (et. al.), even when they clearly abuse the ToS?.

However, this post is about another 'type of hype', if you will. It's that hate-disguised-as-hype that is plaguing the software development industry, and can easily be seen on Twitter/LinkedIn/etc.
I'm talking about the "X is dead" posts. I'm talking about the "if you don't love this just-released technology, you don't know what you're talking about" posts. And ever worse, those "if you haven't migrated all your systems to this new technology, you're X" (X being obviously negative) posts.

Case in point? See the recent "AWS killed microservices" and "AWS killed serverless" posts.

Let me make my opinion perfectly clear:

• AWS did not kill microservices.
• AWS did not kill serverless.

The Prime Video team did not even stop using microservices, they just changed the deployment model for it. If it was a marketing stunt, it was a very successful one, as it can be seen by the number of people talking about it.

Moreover, though, I even recently saw a LinkedIn post that said that you should always use ASP.NET Core Minimal APIs!
Even when it's a new, very immature technology, that it's very slowly gaining features from MVC, people are pushing as the solution to all problems. As if refactoring all APIs to use that framework took one minute.

If you're a software developer/engineer/architect/etc, you should know that. No one technology is a silver bullet, there's no one-size fits all.

If we go back another decade, we can see similar patterns of hype around microservices, SOA, serverless, REST, AngularJs, ReactJs... the list is endless.

Recovering from hype

This post, which I've struggled to think of a good title for, is about recovering from all this pointless, needless, and ever-more-damaging hype.

I'll say this again, because it needs to be repeated quite a few times: there is no silver bullet. Part of your job as a software developer/engineer/architect/etc is to try different technologies and approaches, and see what works best for each particular use case. When things don't work out, or you realize that there are cheaper or otherwise better alternatives, you should be able to change your mind and move on.

It is not about you

The one thing you should always remember is that it's not about you. Your job is not to grow your CV. The decisions you take don't affect only you, they affect your team and your company internally, and it might even affect your customers.

For example, if you are the lead/architect of a team of Python developers, should you really decide to use NodeJs for a new critical service/product? The answer is probably no. Why? Because you're not the only one that will have to maintain that code. If you go on holidays or leave the company, someone else will have to take over. And if you're the only one that knows that technology, and don't have the time or capacity to teach others (which is fairly common), you're putting your team and your company at risk.

Further, if you are the only one that knows the technology, who is going to review your code? In terms of quality (like bugs or style), but also security, performance, scalability, etc.

If the team has the time and capacity, it would be better to introduce the technology for something less critical, and then slowly move to more critical services/products.

Finding the technical substance

If we take ReactJs for example, there's basically a new framework that is supposed to be the next huge thing every other week. It also happens on the wider front-end ecosystem.
You ask a question about how to do something, and you get 10 different answers, all of them using different technologies. If you explain why you want to continue doing what you're doing, you get a lot of hate.

Your job is to see through all that noise. What are the actual benefits of using that new technology? Who is creating it and why? Is it fast/stable/secure/legally usable?

With those "three-lettered images I won't mention", it was obvious that there was no substance behind it. Every time someone asked about it, they got insulted and no actual answers.
A lot of people have realized they can easily cash-in quickly with hyped technologies before it crashes and the hype moves on to the next thing.

Another example of this useless hype is with so called "open-source" LLMs. If you ask, so far most (all?) of them are not actually based on permissive licenses such as MIT.
Rather, the license legally binds you to release all modifications you make to the model and code around it. But they are still marketed as "the first open-source LLM" on Twitter and the like, because it makes people jump on it without even considering the legal implications.

It is not always bad

Don't take me wrong, there are some good things that are mixed with other hype. Take Docker for example, there has been a lot of hype around it, and it has actually given us a lot of benefits over traditional VMs.
Can you, or rather should you, use Docker for everything? Of course not, but it's a great technology that serves a lot of use cases.

It must solve your specific problems

There are technologies that have been hyped and have given us a lot of benefits and they are still hated by a large number of people, like Kubernetes. Why? Because people jumped onto the hype of putting everything on Kubernetes, as if that by itself would solve all their problems. Later, rather than sooner, they realized that other business and technological changes are needed to support that model of working. And some people stopped short of that and blamed Kubernetes for everything.

You can't treat the same technology as being the answer to all your use cases. There's just no single development methodology or framework or stack that is "best" at everything.

Conclusion

I know that people love using "the latest and greatest" technologies, but you need to be able to rationally decide when to use them and when not to. Every decision we take as technology leaders impacts the business. And even if you're not a technology leader, you should help your team find the appropriate technologies.

Finally, if you've read this far, all I ask of you is to stop spreading hate on software development, even when disguised as hype.

People will remember your words/opinions long after that particular hype cycle is dead.