Conteúdos
If you’re a developer, you’re probably a creature of creation — a person who loves solving problems and does it with a smile on your face. It’s what drives your soul into the climax of dopamine discharges.
The software development world is an always-changing environment. Every year, thousands of new frameworks, technologies, and patterns enter the market. These new options lead people to ask whether they’re using the right ones.
“Am I making a mistake by using an old framework when xpto is out now and claims to make my life a lot easier?”
By their nature, a developer is a person who loves technology. Even more so, when the technology is a new one that not many people have tried. Our thirst for knowledge and trying new things is insatiable. There’s a huge adrenaline rush flowing in our veins when we’re creating something new.
Excitement over your profession can be incredible — when correctly managed.
How Can Enthusiasm Over New Things Be Something to Worry About?
It feels like a paradox. Why worry when our programmers are motivated, positive, and thrilled about something new?
Because excitement over a new solution, approach, technology, or pattern, can lead to people overlooking older solutions and claiming, “XPTO.js is the way to go. We should migrate the whole platform to this new framework now!”
The first time it happens, you may think: “OK, we’ll be spending a few months on the migration, but ultimately we’ll end up with a better, more up-to-date product.” After six months of doing nothing but migration, you finally return to focus on business-related features.
One year later, a wild, unique, revolutionary, over-the-edge new database engine appears. Developers are whispering that this is the future and that we’ll be outdated if we don’t change from QSL to Sacandra.
But this time, migrating all the data brings more risks with it. You decide to take the risk. But instead of six months, your team takes more than a year to complete the migration. There were several differences of paradigm between the technologies. There was almost no information about it on the internet and no knowledge about it within your team. Consequently, your customer support got worse, since the engineering team was focused on migrating to a new technology, rather than serving the customers who keep the business alive.
This is Called Hype-Driven Development
Marek Kirejczyk was one of the first (if not the actual first) people to introduce this topic. Hype-driven development (HDD) is developing software and making decisions based on what’s hot at the moment, rather than actual needs.
In his article, he mentions the various types of HDD, such as the conference driven developer, the stack overflow driven developer, or my personal favorite, the loudest guy driven decisions.
There are several examples of hype-driven development out there. Some include, but are not restricted to, NoSQL, Micro-service architectures, and JavaScript frameworks. In these three cases, we verified a lot of excitement around them. Entire conferences and forums went wild evangelizing these solutions. This led to people implementing them, often for the wrong reasons — because they looked cool, not because they actually needed them.
Make Conscious Decisions!
Every framework/solution/pattern/technology was designed to solve a specific problem. Period. This doesn’t make them better than the others — they simply solve a given problem better.
As a professional, you should always ask yourself what the best solution to your problem is. The answer cmay be the most recent, hot micro-service, or it may be the old, side-kicked, unloved monolith. It just depends on the problem you need to solve.
There are no silver bullets.
You will never find a solution that solves all of your problems. It simply does not exist. Every solution will have strong and weak points. When you advise someone to use a particular solution, make sure you match the problem to the most appropriate solution.
How to Detect a Hype-Driven Developer
Bear in mind that often, hype-driven developers are not necessarily hype-driven all the time. is not an HDD all the time. Usually, it happens on topics of interest to the individual.
There are a few questions you can ask yourself to help you recognize when you’re making a decision based on hype:
- Are you aware of the trade-offs that the new solution brings?
- Do you know the specific problem that it was designed to solve?
- Does the solution have proven efficiency in solving a problem similar to yours?
- Do you know the actual benefits the new solution will bring and how much time it will take to get a return on the investment of migrating?
If you answer noto these questions, you’re probably making an emotional decision rather than a rational one. In this case, I advise you to meet with your team, expose the pros and cons of the migration, and check whether it pays off.
Final Notes
As a developer, you’re the source of truth when it comes to technical decisions. This power comes with the great responsibility of advising your management correctly.
Stay up-to-date with everything that’s released every year and make sure you understand the pros and cons of each. Be a connoisseur when it comes to technology — that’s the way to be a great engineer, not recommending something just because you heard about it at a conference.