We live in a time when every month brings a new framework, library, or architectural pattern that promises to change everything. Increasingly often, we come across a new technology, a new trend, and most possibly, a new hype. And we, developers, somehow lose sight of the goal we want to achieve and, sadly, embrace the hype instead.
It starts innocently. We hear how a big company solved its problems with a new tool. We see posts about revolutionary frameworks or must-have practices. Soon, teams begin rewriting working systems or adopting unfamiliar tools, not out of necessity, but out of fear of being left behind.
There is a certain comfort in hype. It makes us feel current, part of a larger movement. Yet, this comfort often comes at a cost. In trying to stay modern, we forget the fundamentals — clarity, simplicity, and solving the actual problem.
In an effort to bring the hype into the game, we can create a huge technical debt from day one. The irony is that hype-driven decisions rarely look wrong at first. They seem smart, exciting, even visionary until maintenance begins. Then the complexity reveals itself.
Hype in Software Development
What kind of sorcery is this?
Developers write obscure code because of the hype about fewer lines of code. The fewer lines of code we write, the smarter/knowledgeable we are. The true sorcery, sigh... On the contrary, the hard part is rather making it clear enough. If we can't understand the code after some time, it's almost a crime scene. For every little change, we need to investigate the same crime again and again.
Dare to enter my abstract factory
The developers sometimes apply abstraction too eagerly. Perhaps, they want to create most generic program ever or they want to apply a cool pattern. Suddenly, they can end up in a magical world where we lose the sense of the reality and what the problem was. The abstraction isn't free and applying right level of abstraction might be hard. In the end, you might become architecture astronauts.
NoSQL rocks
Have you ever used a NoSQL database with relational mindset? Back in the days, I have seen this getting applied. Multiple documents that represent the domain similar to relational databases. Nonetheless, we didn't have foreign keys, joins, and transactional guarantees. Yet, somehow it was the "right" choice. What's more, it was web scale.
Scalable database
Who wants their databases to scale indefinitely. So, why not use a scalable solution like Cassandra from day one. Many developers used it. Well, if you are inserting less than a million rows a day, does it still make sense to use a solution like it? What about provisioning, deploying and maintaining such a complex system?
Microservices first
Some big company saved their organization by adopting microservices. It's proven to work for them. So, what can be wrong with microservices? Maybe there's nothing wrong except the fact that the development team is 3 people. Or, you never had anything that provides some value.
Contemporary queue
If you have a line of things to be handled like some sort of tasks, you can use a queuing system. We needed such software. Our developers wanted to use a Redis for queuing because of the hype. They have used it. At the time, it lacked library support and wasn't resilient enough. There was an option of using existing battle-proof technology yet it didn't happen. Hence, the developers got lost in the dark with no light and getting support duties constantly.
frAGILE
Agile frameworks won't fix your organizational problems. Moreover, inventing buzzwords like "organic agility" for your organization wouldn't provide anything either. Most of the organizations fail to take into account the very core of agile manifesto. Quickly, the organization ends up in a people depth: roles, methods, and inconsistency. After all, the time and money get invested in the wrong place without thinking about the return on investment.
Java sucks
Yes, it does. And, your team decided to choose a brand new programming language that doesn't suck. Over time, things can go south and you might realize the fancy new language wasn't that good after all. It lacks framework support, IDE integration support and so forth. All in all, it starts to make your life miserable. This isn't really about Java but a more general case for the programming languages. Every language has its advantages or disadvantages. Some of them are great at getting something done fast and some of them are low level and so on. One should be careful about getting excited about new languages.
Java became the symbol of “boring” software only because it works too well to be exciting. It’s not meant to be fashionable; it’s meant to be reliable.
Frontendlessness
The frontend development is the mother of hypes in software development. There are hypes about tooling, language, frameworks and almost everything. Everything changes so fast and people too often gets enthusiastic about new stuff. Hence, I'm not able to list anything here as it might get obsolete soon. The hypes in front-end development make developers feel old. The sad thing is we can't even avoid hypes in front-end development.
Nobody cares about these hypes. The only thing that matters is to make one's life easier through writing software. On the other hand, you might even make someone's life harder because of the hypes. So, do be careful.
tl;dr: Don't believe the Hype