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

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.

The first language I learned was HTML, back in… I don’t remember the year, to be honest. There was probably something before HTML, but it’s so embarrassing that I wouldn’t dare mentioning it on the Internet (mIRC scripting anyone?). With HTML, I built all kinds of useless websites: e-stores that were really just a bunch of static pages tied together, intranets where the sign-in form was not pointing to anything… Not exactly mind-blowing stuff. But I was probably not even 10, so that was more than enough to keep me entertained in the summer afternoons.

In one of my numerous adventures on the Internet, I discovered PHP — and no, it was not love at first sight. I tried to learn it, but I would inevitably stumble into some problem that I didn’t have the patience to overcome, so I gave up. And gave up. And gave up. I think I tried to teach myself PHP four or five times, failing every time.

Fast forward five years — I’m a contributor to the Symfony framework, I write my own open-source tools in PHP and, of course, I built many complex web and CLI applications with the language that I was once struggling to learn.

The same thing happened with my quest for learning Ruby: I tried twice, but I just couldn’t grasp some of the most basic concepts behind the language, like blocks. It seemed cool, but it also seemed so unnecessarily novel and different from what I was doing. Eventually I gave up and sticked to PHP.

After growing more and more dissatisfied with some of PHP’s quirks, I stumbled into Ruby once again. This time, it took me less than a day to grasp the fundamentals, and a couple of weeks later I had written my first mildly complex app with Rails.

Today, I’m still writing and loving Ruby. I have created tens of Ruby apps and I’m the maintainer of several OSS projects (which no one uses, but still!), including a framework for building better RESTful APIs.

So what happened? What was blocking me from learning PHP and Ruby? Perhaps I wasn’t smart enough, or didn’t have enough experience?

“There must be something else,” I said to myself for some time, without being able to quite grasp what was standing on my path.

Then I realized: in both occasions, I simply wasn’t ready.

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.

All their performances have the same structure: one of the musicians starts playing a tune and is then joined by the other two. They play independently, and yet their figures are unmistakably intertwined. For many, attending a live performance by The Necks can be an excruciating experience: they tend to repeat the same piece, adding the slightest variations, over and over, for up to two hours.

Then, when enough momentum has built up, the music changes and the piece moves to the next phase of its life.

The same thing happened to my learning: when I first tried to learn PHP, there was simply not enough motivation for me to do it. But when I went back to PHP a few years later, the situation was much different: I had spent enough time with HTML to know where it was holding me back and what the next step in my development would be. I was happy with PHP for some time, which is why I couldn’t commit to Ruby — when I finally realized that PHP was holding me back as well, I learned Ruby.

It was a matter of time, not of IQ. I couldn’t learn because I hadn’t built up enough momentum.

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.

Armies of inexperienced, eager developers join the bandwagon, yearning for a new technology to try out. Dozens of articles emerge about how the existing tools are inadequate and the new one is so much better and ought to be adopted by everyone. Startups start hiring developers proficient with the new technology, without really knowing whether it will be of benefit to their particular challenges — but hey, if it’s new, it must be better, right? Meanwhile, anxiety builds up in those who haven’t caught up yet — and are sure they’re going to be unemployed in six months.

Seasoned developers scoff at this collective hallucination, because they know that it’s just one phase of the hype cycle, depicted below.

If you have ever witnessed the birth and development of a new technology, you know that this graph is pretty accurate. Here’s a short explanation of each phase:

1. Technology Trigger: first, some kind of trigger (like a cool proof-of-concept) causes the new technology to gain overnight fame.
2. 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.
3. 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.
4. Slope of Enlightenment: the maintainers and some late bloomers define the problem domain more clearly, improving the software and making it more specialized.
5. 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.

This is true for all languages, libraries and frameworks the community has ever built. The next time a new tool pops up in your RSS reader, try to follow it as it goes through the different phases. Sometimes it might take years, but it’s an exercise that pays off in the long term, as you learn to distinguish hype from justified excitement. In my experience, it’s one of the traits that only the best developers possess.

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:

• Don’t jump on the bandwagon. When something new comes out, wait. Look at the graph above and know that it’s only in the first stage. New tools are untested, they have small communities which are usually blind to the tool’s shortcomings. Let time be the ultimate beta tester. Time separates signal from noise, so allow it to do its job.
• 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.

If you follow these tips, your work will benefit from greater stability, but you will also be able to incorporate any interesting pieces of software with a high degree of confidence that they are stable — or that any instability will be contained by the safeguards you wisely put in place.