DX and Dev Tools' place in the Hype Cycle
Last updated on
- #DX
- #Dev Tools
- #Opinion
- #Startup
I’ve always believed in Dev Tools. Recently, there was a surge in popularity of Dev Tools and improving the UX a developer experiences. I got really excited a couple of years ago when I saw startups emerging in this space. But recently I hear that this whole field was deemed “too expensive” or “not worth it” by both potential customers and even investors.
I fundamentally disagree with this sentiment. I agree that today it’s too expensive, but I disagree with investors who don’t believe in the future and potential of DevOps tools.
I’d like to explain why I think this recent decline in popularity is actually very natural, and is not a strong enough signal to keep me from working in this field.
The Hype Cycle
The Gartenr hype cycle is a simplified model to
“represent the maturity, adoption, and social application of specific technologies”.
It’s a good model, which we won’t dive deep into in this post. However, for those who are unfamiliar with the hype cycle, the idea is that when new tech emrges, it initially goes up in so much popularity that it becomes a bubble, which collapses but eventually recovers and stabilizes.
This is of course an idealized model, and it is careful not specify how long each step takes. It also doesn’t specify how high are the peaks and how low are the lows. The “Pleateau of Productivity” (see image above) might end up being very close to zero. You can see below how they add that dimension of time by coloring the dots on the graph.
You can see an example on Gratner’s Blog where they try to place different technologies on this curve. This is an example for AI:
I find Gartner’s model useful when I’m thinking about the next thing I want to work on. I want to solve actual problems. Duh, right? Who actively wants to work on something useless? (A lot of people actually. But that’s besides the point)
The point is that the most basic human way to figure out if something is real is to simply ask around!
- Hear a sound in the middle of the night? Wake your partner!
- Have a hard school assignment? Ask your friends if it’s also hard for them.
- Don’t know the capital of Germany? Google it!
This usually works, right? Well, usually yes, but the Gartner model suggests there’s a caveat. The model says that it takes time for people to understand what you can and can’t do with a certain piece of tech.
Meaning, at scale and on average, it takes time for society to understand the real value of a certain piece of tech.
Well, ok. This is pretty abstract. It’s not very concrete on how long this cycle takes and how to get around this.
But for me, this is a reminder to try to consider multiple data points before ruling out a potential tech just because it’s current public opinion is that it’s not good enough.
How I see Dev Tooling
I’ve always been interested in the effect the tools we use on the products we build. I understand that this belief system exposes me to confirmation bias towards the effectiveness of Dev Tools, so I’d love to hear from you if you see me hand waving too much here;
I believe the tools we use to build things have a tremendous amount of influence on the products we end up building. Checkout Bret Victor’s Talk on YouTube to dig deeper into how exactly. But the main point is that an immediate feedback loop from the tools is very valuable to the human brain.
Practically, for me it translates to the idea that good observability tools and automation are the main drivers of innovation in tech. This should in turn generate more revenue than what you spent on the observability and and automations, creating a positive feedback loop ♻️.
But how? Well, the gist theory is that it is easier for our constrained brains to think and explore ideas if we can offload things are brain does into the computer. For example with observability, consider Traces - we can’t really understand what is going on if we look directly at the trace data, but once we put it on a nice graph, we can reason about the flow very intuitively. For example
How the industry looks at Dev Tooling
This idea has gained popularity in recent years. A lot of technical organizations started to spend money and effort on DX and Dev Tools. There was a surge in evidence about how DevOps practices can raise profits and reduce costs for any modern company. This movement was a trigger for tech companies wanting to spend more on “Developer Productivity Tools”, “DevOps” and similar buzzwords. Makes sense.
However, if we look how it turned out in the industry, it seems like DX does not really live up to the expectations.
At the top we can see “Internal Developer Portals”, which seems great! But when I look more closely, I can’t really find any other tech that focuses on the Dev Experience, maybe expect for GitOps.
Most of the emerging techs are AI related as far as I understand. It makes sense that AI is showing up all over the hype graph - just open your favorite social network and in five minutes I bet you’ll see someone talking about AI.
But if you scroll twitter looking for someone talking about Internal Developer Portals (IDP) or GitOps, I bet you won’t see it as much.
And it’s not just on social. From my personal experience, executives in companies are reluctant to spend more money on Dev Tools. What usually happens is that the dev tools they buy and use don’t live up to the expectations set in the literature or by the product they bought. So companies deprioritize Dev Tools in their budget lines in favor of, usually, some AI tech trying to solve the same underlying problem.
The thing is, I don’t see this as a problem. This sentiment I hear actually aligns with the Hype Cycle! In other words, there were inflated expectations towards Dev Tools! It’s just part of the hype cycle! Nothing to worry about!
Overcoming the Trough
So up until now I hope I convinced you that Dev Tools were in the Peak of Inflated Excpetations, and are no longer there.
Now I want to look at the future. Where are we on the graph now? And, more importantly, where are we headed on the graph?
Zooming out of the Gartner graph above, I want to remind you that Dev Tools are much more than Portals and GitOps. I’m missing some important concepts, like:
- Internal Developer Platform
- Progressive Deployments
- API Docs Generation
- On Demand Dev Env
- Observability
I think there’s potential here because of that. It seems to me that there’s a gap between the expectations executives have and the actual products they buy. Dev Portals and GitOps are not sufficient to create the type of culture and environment that the DevOps movement advocates for.
In the language set by Gartner, I think we are way down on the Trough of Disillusionment because we have a lot of Enlightenment to do! In other words, I see a big enough gap between what the theory and litrature promises and what the current technology actually offers.
This makes me confident that it is only a matter of time and effort until we figure this out.
Developer Productivity is an Iceberg
There’s a lot more to Developer Productivity and tooling than what I can possible fit in this blog post. I think the industry is only scratching the surface of what is possible and needed.
My best analogy is the famous Iceberg meme (example). From “above water”, Developer Productivity seems like a new idea with simple solutions. Looking at the Gartener analysis, it seems like creating an IDP and working with GitOps practices covers a lot of ground.
But once you actually dig in, there’s soooo much under the surface of the water! I won’t even attempt to enumarete things myself in this post. There are much better qualified resources for that.
In fact, this week Dave Farley, a veteran in the Continuous Devlivery space, published a YouTube video reacting to an article aimed at executives that is filled with misinformation that goes directly against the science. He explains it better than me so do checkout his video 😉
For me, what Dave is talking about is a good positive signal that there’s much more potential to be extracted in this field. It’s clear to me that the science of how to build a productive and successful software company is simply not yet understood or implemented.
Next Steps
I think this post is a good (enough) explanation of why I’m trying to solve problems in this space. I think there’s value here.
How to achieve this is a different topic, which I plan to write more and more about 😄
Hopefully you found value in reading this as well! If you did, stay tuned to hear more 🙌
Cover photo by Tim Marshall on Unsplash