Hype(R)! Hype(R)! How to Beware of Hype and Stay up to Date Nevertheless

How to deal with the dangers of hype, keeping teams motivated and at the cutting edge while retaining a solid technological foundation. Inspired a great deal, by Hype Driven Development by Marek Kirejczyk, of daftcode.pl.

Hype Driven Web

The web as such has always been characterized by short, fast paced cycles of evolution. No medium allows for a faster and more absolute rise (and fall) of the ever new. It is no surprise then, that we experience the same circles of boom and bust in regards to software development for the web.

Hype Driven Web Development

No day goes by in web dev land without the release of a new language, framework or library. At times the whole eco-system seems to be caught in a shape shifting frenzy. In the last two years we (might have) moved from jQuery to Angular to React back to Angular 2 and then on to Vim… and that’s just the major frontend JS frameworks.

Not only is there a constant stream of new tools and toys, each of them is promising no less than a paradigm shift in how we do our work, landslide gains in regards to productivity and capabilities as well as quick, elegant and final answers to most development brain teasers. There also is the hype. A constant chant in Social Media, forums and mailing lists alike. Reaching out and asking us to join the cult around tool X and technology Y.

There is no malice behind this, as Marek Kirejczyk beautifully captured in his article about the anatomy of hype. It starts with the invention of a solution to a problem specific to a certain team. The spreading of excitement about said solution, the build up of hype and (over-)generalization of said solution. And lastly, the disappointment, that it might not be the magical solve all we imagined it to be.

Anatomy of a hype: Hype Driven Development, Marek Kirejczyk.

Check out Mareks article for examples, ranging from React, “TDD is dead” and Microservices to NoSQL. Each of these is a great tool or paradigm, that, if used right might save you from a headache or two. But if used wrong might cause a hell a lot more than just a headache.

Dealing with Hype the Classic Way

Still, developers and managers alike are facing the task of finding a balance between the adaption of new technology and the preservation of a solid foundation for our teams and projects to keep working reliably. This can only be solved by systematically approaching the process of technology absorption and adaption.

A first step would be to ask questions such as: What problem are we trying to solve here? How long will it take till we adopt this tech as a team? What will be the effects on our teams structure and processes? How long will it take till we reap its benefits? Do the benefits outweigh the costs?

Dealing with Hype the Lean Way

Already asking these questions gives us an advantage over blindly adopting and introducing technology. Often though, we might want to gain a deeper understanding of the technology at hand. In that case, we might employ an idea from Lean/Agile/XP development: Short controlled trail runs.

  • Hackathons focus on technology. Which means, open ended, broad trial runs, aiming to provide us with a general understanding for the costs and capabilities coming from the use of a certain technology.
  • Spikes are problem focused. Meaning the use of short, focused trial runs of different libraries, frameworks and tools to evaluate if they might help solve a specific problem.

In order to be effective, both formats need to be clearly goal oriented. They also need to be limited in regards to time and resources allocated. Satisfying that criteria, they can provide a good way to both motivate teams, expose developers to a healthy dose of innovation and reducing the risk of letting technology decisions being driven by hype at the same time.