The Hype Cycle: What It Is and How to Game It

Stop worrying and love what you have.

As a CTO, one of my responsibilities is to constantly research technologies that will enable my company to stay ahead of the competition. It might then come as a surprise that, for the longest time, I’ve had a lot of trouble studying and understanding new tools and languages.

Momentum and Evolution

I don’t listen to jazz very much, but a couple of years ago I discovered The Necks. For those of you who don’t know them, it’s an experimental jazz trio and, as you might expect, they play the kind of music that you either love or hate. For me, it was definitely the former.

FOMO and the Hype Cycle

Fear Of Missing Out (FOMO) is very real in the tech industry: if you have ever heard at least one joke about how many libraries there are in JavaScript to do the same thing, you know what I’m talking about. Every day a new tool emerges that promises to be the everything-killer, to end all problems and to guarantee maximum productivity to everyone, everywhere.

  1. Peak of Inflated Expectations: everyone and their mom start to use the new tool, almost inevitably for problems it is not supposed to solve. This is also because, at this point, not even its maintainers fully understand the problem domain.
  2. Trough of Disillusionment: as projects start failing because the new tool is falling short of people’s expectations, it is labeled as a complete failure. The technology is partially abandoned.
  3. Slope of Enlightenment: the maintainers and some late bloomers define the problem domain more clearly, improving the software and making it more specialized.
  4. Plateau of Productivity: developers who initially abandoned the new tool come back to it with a fresh perspective and, using it for the right job, are able to achieve maximum productivity.

Gaming the Cycle to Your Advantage

So how can you make the most of the hype cycle? Here are a few tips that will ensure you only start using a tool when it makes sense:

  • Learn your tools before switching. The 10,000-hour rule is real. 10,000 hours are approximately five years of full-time work — it is not just a coincidence that it took me about five years to master PHP and five more to master Ruby. If you are constantly switching to the shiniest technology, you will only scratch the surface and never fully understand anything, which will prevent you from reaching your full potential.
  • Resist FOMO. Every time a new project comes out, it is prophesied that the old ones are doomed. Guess what — PHP is still here, Java is still here — hell, C++ is still here too, sadly. Solid tools with a solid foundation are here to stay. On the other hand, if I had a dollar for every “revolutionary” library/language I’ve seen rising and falling, I’d be rich by now.
  • Don’t stagnate! Nothing good would ever happen if it weren’t for the few brave people who are willing to lead our industry by creating, testing and advertising the most unstable technologies. You should not live under a rock: keep up to date on the latest developments of your field, contribute to and play with new projects if they seem to have potential. You shouldn’t stagnate — just don’t heavily rely on anything that might be gone for good in less than a year.
  • Isolate unstable dependencies. As a corollary to the above: there are patterns you can apply in your project for experimenting safely. A few of them are the adapter pattern, the proxy pattern and the circuit breaker pattern. If you learn to implement these, you will be able to test new dependencies without the risk of them negatively impacting your work.

Technology leader and strategic advisor. I work at the intersection of people, software and words.