Leaving the rat race - Part 2

In the previous post we discussed the omnipresent FOMO and the resulting feeling of continuously running a Red Queen’s race for many of the affected people. I also discussed that based on my observations this impression of such a continuous high “innovation” speed is mainly driven by an IT hype industry which benefits from people who are in a constant state of FOMO.

In this post, we will discuss if we are really as innovative as we claim to be.

The lack of true innovation

Fueled by the ubiquitous youth craze in IT, in IT we tend to think that young is “good” and old is “bad”. This is not only true regarding people ¹. It especially is true regarding tools and technologies. The newer something is, the better it is considered – because: We are so “innovative”! We never stand still! We move so fast, so much faster than any other domain! We innovate all the time! Therefore, the newer something is, the better it must be.

This twisted self-image perfectly supports the FOMO spread by the hype industry, I discussed in the previous post: If there is a new hype, we think we cannot afford to miss it because this is a new thing. And newer is better. And we move so fast, because we are so “innovative”. If we miss it, we will fall behind. Hence, we cannot afford to miss it. The “so innovative” self-perception and the hype industry perfectly complement and fuel each other.

But are we really as innovative as we claim to be?

From all I have seen, we are not more innovative than most other domains.

But what brings me to that observation?

A while ago, I wrote about the disruption delay, that it takes about 20 years until a disruptive IT technology arrives at mainstream.

If you look at the images in that post, they do not only illustrate the delay. They also illustrate the frequency of disruptive innovation, i.e., true innovation that leads to something actually new, being it new IT usage patterns, new business models based on or supported by IT, or alike. If you look at that, you realize we do not have that much true innovation in IT.

Evolution labeled revolution

But if it is not true innovation, what else is all that other stuff, we call “innovation”?

Most of the times, we create the same things over and over again, each time a bit differently. If we are (un)lucky, the IT community, industry and media jump from the first to the second to the third solution, all solving the same type of problem. And each time they call it a groundbreakingly new “innovation”.

E.g., look at (parts of) the Javascript web frameworks and libraries of the recent years: Ember.js is it! No, Angular is it! No, React is it! No, Vue.js is it! Nonsense, Svelte is it! And so on. And this is just the tip of the iceberg regarding web application development with Javascript of the last 7 or 8 years.

Tons of other “revolutionary” tools and technologies are missing. Did I mention Next.js or Nuxt.js, of course making the aforementioned frameworks and libraries obsolete? Or all the different JAM stack implementations like Jekyll or Gatsby that declare SPA obsolete and predict a future of generated static web sites? And so on. ²

You can easily get lost in trying to keep up with the evolution of the Javascript ecosystem for web application development. But in the end, is there anything revolutionary new? No. All of these technologies serve just one goal: They help building web applications. Nothing new. We do that for more than 25 years now.

Admittedly, there was quite some evolution in that area. A web site like, e.g., Google Docs was not possible in 1996 – at least not in terms of a smoothly working browser app. Still, it is just web application development. In terms of innovation this is old, old hat. Evolution? Yes, a lot. But that is not a surprise. After all, we talk about 25 years. But revolution? No.

Do not get me wrong: This is not a case against web application development and its tooling. We need web application development. We need lots of it. Thus, do it if that is your turf! I really admire people who know how to create great UIs, providing a smooth user experience that are fun to use. But, e.g., switching from one framework or tool to the next is not “innovative” just because the new framework offers some nice new feature. It is still web application development. Nothing less, but also nothing more.

You might say that Javascript-based web application development is an extreme example, that other IT communities are not that “crazy”. Well, I do not know. I do not think the Javascript community is better or worse than any other community in IT. Regarding the rat race, I think they are quite the norm.

If you look, e.g., to the Java community, every 6 months you get a new language version and every time you are drowned in a plethora of talks and articles, explaining all the “innovations” of the new language version, why you cannot afford to miss them and that you are old hat if you do not use them.

New versions of Java libraries and frameworks also let you run off your feet. On the application server side, we need to know all the “innovative” details and options of the GraalVM, Micronaut and Quarkus, of course. And if you want to play with the cool kids on the block, there is no way not knowing the -XX options of the newest JVM. Thus, in the end: Different community, same story.

You find a similar situation in most other communities. Additionally, we are flooded with IT-wide trends, affecting all those communities and leading to additional orthogonal communities (you also “cannot afford to miss”): Microservices, Domain-driven design, Cloud-native, API <Whatever>, <Whatever>Ops, Event<Whatever>, <Whatever> Mesh, Observability, Serverless, Cloudless, IT-less, … ³

But all that stuff that keeps us running our feet off, that occupies all our capacity and leaves us totally exhausted is not “innovation”. At best, it is evolution. Often, it is not even that but just old wine in new skins, the Nth solution for the same problem, claiming to be “revolutionary new” … again.

True innovation

But, do we not have any real innovation in IT? Are we just reinventing the same wheel over and over again?

Well, of course we have some real innovation. If we look back the last 20 years, e.g., we see:

• Smartphones – revolutionizing the way people interact with IT (“People no longer go to the Internet. The Internet goes with them.”)
• Public cloud – turning many IT services into commodity, extending the “make or buy” model, enabling new ways of creating and running software, leveraging completely new types of IT-based solutions that were not possible before
• Big data – paving the way towards near-realtime analytics, data-driven companies and using data as an asset
• IoT – connecting OT and IT, preparing the ground for ubiquitous IT and more
• …

If we carefully look at this list, we do not see hundreds or thousands of innovations in the last 20 years, but rather around half a dozen true innovations. And even if I forgot to list some innovations (which is not unlikely), most likely we still would not exceed the dozen.

And what about containers?

Containers also were a really important development of the last 20 years. They helped to adjust the boundary between OS and application: The application and all its dependencies live in the container. The OS – typically a distributed scheduler like Kubernetes in such a context – is responsible only for managing access to resources like compute, storage and network.

Containers helped us to escape the dependency hell where applications depend on prerequisites that need to be available at the OS level: Dynamic libraries, language runtimes, application servers, etc. Containers helped us to move the boundaries between applications and the OS back to where they were when the separation between OS and applications started many, many years ago, when the OS was a resource scheduler and nothing else.

Still, containers were nothing new. They existed for many years before. Docker only made it easy using them which kicked off the very fast container adoption wave. So, containers themselves were not an innovation. The true innovation was Docker making container usage easy for everyone.

Dealing with a Cambrian explosion

I would like to mention one more thing before wrapping up: The Cambrian explosion of tools and technologies we always face when an innovation takes off and before the consolidation kicks in. This explosion is part of the market forces when many parties try to secure their share of the market, when they all release competing solutions, all addressing the same problem.

While this is a normal evolution, it can still feel stressful from a developer’s perspective because it feels as if the number of new tools and technologies “one must learn”, well, exploded. Additionally, the tool vendors and consulting companies maximize their efforts to make you believe you cannot afford to miss their offerings because – as written before – they try to secure their share of the market. As a consequence, the number of “cannot afford to miss” messages they send also explodes in those times.

This is perfectly understandable from a vendor’s point of view as they all fight for their share of the cake. But it also makes it harder for the people targeted not to be swept away by all this marketing power and end up in a state of full-blown FOMO.

So, how to deal with Cambrian explosions and the resulting explosion of “cannot afford to miss” messages?

From my experience, it is okay to relax. Yes, something innovative is about to unfold and it is important not to ignore it. But – and this is important to keep in mind – it is not important to know all the new tools and technologies that emerge in those Cambrian explosion times. Always have in mind: Most of them will be gone in 2 or 3 years’ time after the inevitable consolidation that comes after the explosion has done its work.

Therefore, observe at what is going on. Maybe, take a closer look at a promising early competitor. Watch the evolution of the unfolding ecosystem. Then wait for a while until a winners of the race becomes apparent.

This is the point in time when the effort-value relation of picking up a new tool or technology is best. There are only few tools and technologies left. There will be lots of excellent learning materials available. The tools and technologies themselves meanwhile are also quite mature.

But you are still early enough before the innovation becomes pervasive. This is the sweet spot between the early adopters who struggle with dozens of competing, bleeding edge, poorly documented solutions and the late adopters who miss the point in time when an innovation becomes pervasive.

Thus, yes, you will need to pick up the innovation at a given point in time. But you do not need after dozens competing technologies while the Cambrian explosion takes places. You do not need to submit to the “cannot afford to miss” messages. Instead, it is perfectly fine to watch, select and pick things up at your own pace.

Summing up

In this post we have discussed that we are by far not as “innovative” as we claim to be. Most of the innovation puffery comes from the hype industry, trying to lure and force people into buying their products and services.

True innovations are relatively rare – maybe 3 or 5 innovations per decade. Of course, each innovation brings its Cambrian explosion and consolidation wave. But if we understand that, we can observe it in a relaxed way and channel our energy a lot better, not running our feet off in a constant state of FOMO, but making deliberate decisions that leave us enough room to think and breathe.

In the next post, we will look at the next reason why I think, running the Red Queen’s race does not make sense: The distraction from our perennial actual problems, that we are always on the lookout for the next silver bullet we hope will magically solve our perennial problems, the same problems we face for many years meanwhile – instead of tackling the problems themselves. Stay tuned … ;)