What is Hype Driven Development?

This term has become quite prevalent over the last year or so in the applications developers community, which is quite apt given its definition. Hype Driven Development refers to decisions taken during the development process, especially early on, based on the current flavor of the week/month/year that has the most ‘hype’ around it from the development community. These are vital decisions that have ripple effects across every aspect of the product, from its budget to its delivery date & quality.

As new technologies emerge, they can be really attractive to (to developers especially). The feeling can be compared to that of a child having a new toy which they want to play with. Don’t get us wrong, this is not a bad thing. Developers should get excited by new technologies and have the desire to play with them, learn them, and understand their strengths and limitations. They open up brand new avenues of possibilities that were previously unachievable, or perhaps just too complex to venture towards. However, it is equally important to know which situations these technologies are best suited for, and not try to forcefully use them in your next project just because everyone is excited about them.

The biggest example of this currently is Blockchain. The number of people who have approached us to build “some Blockchain element” into their application is quite staggering. Even if the product is currently live, has users, traction and a year long roadmap already in the works, stakeholders are eager to disrupt all of those things in order to shoehorn Blockchain into their product. In a vast majority of these cases, Blockchain will add no benefit to their product — in fact, it will be detrimental. However, these objections often fall on deaf ears and are met with an extreme amount of resistance. Why? Because the hype surrounding Blockchain is immensely real. The decision makers are keen to be ahead-of-the-curve (which can be a good thing sometimes — but not in this case).

The same can be said for other development technologies that continue to emerge or evolve and make the legacy stuff look weak in comparison. While that may be true, there is a cost involved with refactoring, or in some cases rewriting a massive code-base just because. There are genuine cases where the upgrade is warranted, however, this needs to be considered from several angles to ensure that the rework involved will be worthwhile in the long-run and won’t just succumb to another new framework or technology in the next 6-12 months, igniting another rewrite.

In the case that a new project is being initiated from scratch, these decisions are equally important. Rather than gravitating towards the exciting and shiny new technologies that are the talk of the town, we as application developers must be cautious with the technology stack that we decide upon. Several factors come into this decision, such as the project’s actual needs & requirements, resources available, the team’s strengths & weaknesses, infrastructure, budget, timelines & training considerations to name just a few. Failing to take these matters into consideration and building a product on the latest and most exciting technology just because you are buying into the hype is a recipe for failure.

Lastly, it is important to keep in mind that new technology usually takes a few years to properly mature before it is ready for primetime. There are of course always exceptions to this rule, but it has been a general rule of thumb that has held up pretty well over the years. Industry support, thorough documentation, battle tested use-cases and community buy-in are all factors that play a major role in evaluating a technology’s place in the lifecycle.

In conclusion, we would advise not taking these decisions lightly and focusing more on Performance Driven Development rather than Hype Driven Development. Focus on the requirements of the project, as not all projects need you to have the latest cutting edge technology in order to maximize its benefit. Building custom software and applications provides an advantage over off-the-shelf products because they are tailor made for the requirements and not bloated. Utilizing technology that is unnecessary for the project is counter productive and misses the point entirely.