0 Comments Posted in:

Whenever a new development technology is announced I'm usually near the front of the queue to try it out. Over recent years this has included things like Durable Functions, Kubernetes, Dapr, Tye, Pulumi, Blazor, etc, etc. I like to dive in deep and try them out, often while they're still in pre-release to evaluate whether they would be useful for my own projects. Out of that I'll often blog about my findings and sometimes do conference or user group sessions.

Sometimes I find that people are surprised to hear that although I might be blogging and talking about a new framework, I'm relatively slow to actually start using it in production. That's because although I think there is benefit in being quick to evaluate new technologies, I also think there is wisdom in being relatively slow to actually adopt them.

Benefits of being an early evaluator

Here's some of my top reasons for being quick to evaluate new technologies.

First, with any new tech, don't believe the hype, try it for yourself. Every new framework is launched with a fanfare of spectacular claims about how it will revolutionise everything. Occasionally something really does live up to the hype, but the best way to get a realistic picture of what a new technology can do for you is to actually try it out. I like to build something small that is representative of the type of use I'd want to put it to in the real world.

Second, ask the question, does it solve a problem I actually have? The most common motivation for creating a new framework is that it solves a limitation or weakness of existing tools. But the problem it solves may not be the problem you have. Kubernetes is awesome, but if you're just building a blog its probably overkill.

Third, I want to find the missing features. No new framework drops feature complete in version 1. It maybe does 80% of what you want, but quite often I find that there is a missing feature that is a showstopper. This might be something like regulatory compliance. In this case, you simply have to park your interest in the new framework until it offers the functionality you need.

Fourth, by trying things out early, you have a real chance to shape the roadmap. When new projects are in beta, they are typically very open to suggestions for improvements, and willing to make changes of direction to accommodate use cases the creators hadn't initially considered. These sorts of changes become much harder to make once an initial v1 has been released, so it's good to get involved in the discussion early.

Benefits of being slow adopter

Why do I tend to be a slow adopter, even when my initial evaluation of a new technology is very positive? A few reasons:

First, I like to give it time to stabilise. Early in the lifecycle of a new framework, breaking changes tend to be more frequent. This can be very frustrating if you were quick to go to production and you find yourself forced to spend a lot of time migrating to new versions.

Second, you also need to give it time for its feature set to become well-rounded. As I said above, new frameworks might do 80% of what's needed, but there are often rough edges and missing features in areas like observability and resilience. Jumping in too quickly can cause a lot of pain and sour people's opinion of the new framework.

Third, leave time for its weaknesses and flaws to become apparent. There will be plenty of people who do rush to production with a new technology, and if they find that it falls over at scale, or has unanticipated pain points, they will be quick to share their negative experiences on social media. This can give you valuable information about the types of problem that you might encounter yourself that weren't apparent with a simple demo app.

Fourth, leave some time for competitors to emerge. Sometimes an innovative idea sparks other new frameworks that take that idea an go even further. This seems to happen quite frequently in the JavaScript world for example with a series of SPA frameworks each stealing the best ideas from each other and adding a few improvements of their own.

Fifth, sometimes even when you really want to adopt a new technology as soon as possible, legacy code gets in the way of moving quickly. If you're not on a greenfield project, you often need to strategise about how you will migrate your legacy code to the new framework. Depending on how much of it there is, this may need to be a multi-year strategy.

Sixth, you need to reserve sufficient time for training developers and operations. For example, to effectively use Azure Durable Functions, there are some really important rules you need to know about what can and can't be done in an orchestrator function. And to troubleshoot failed orchestrations, there are some tools and techniques that operations staff need to be familiar with. Rushing out a new technology without sufficient training is a recipe for disaster.

Finally, I am very aware of the need to avoid over-promising and under-delivering with a new technology. It's easy enough to say "if we just move to Kubernetes it will solve all of our deployment issues, and give us huge cost savings". But then if the initial roll-out doesn't go smoothly (which is often the case when you're using something new for the first time), there will soon be recriminations.

Summary

I like to devote some time each month to learning about and trying out what's new. Resources like the Thoughtworks Technology Radar are great for this. But I am much more cautious about actually pushing something new into production. Do you agree with my approach? Let me know your thoughts in the comments.

Want to learn more about how easy it is to get up and running with Durable Functions? Be sure to check out my Pluralsight course Azure Durable Functions Fundamentals.
Vote on HN