Few weeks ago I've noted down an interesting notion that someone has mentioned during one of the discussions I've participated in:
hedging technology
The overall idea is simple, you may recognize it from hedging funds or hedging bets. Hedging technology is expanding your area of expertise in a particular field by learning another technology that basically applies to (/enables) the same scenarios as your primary choice tech (in that field), but significantly differs in terms of technical foundations:
- has completely different base dependencies (e.g.: platform, OS)
- utilizes different skillset(s) (e.g.: language)
- sometimes even represents completely different approach (but still, to solve the same class of problems) (e.g.: message broker VS persistent actors)
In other words - a high degree of mutual independence is a key point here.
Why spreading thin?
What's the purpose of hedging? To always have an alternative (for potentially failing component) - if you're struggling with the technology & due to some reasons it just doesn't work as you've expected (doesn't work enough, performance is too low, constraints are unbearable, etc.), sometimes there's no point in going forth. Ambition is important, but making it personal is very selfish & may end up in wasting a lot of time & effort. That's why at some point you have to pull another ace from your sleeve - substitute the failing link with something different, deprived of the root cause of original's failure.
Obviously it doesn't really affect the shops that work with the same technology for years, without any experiments or try-outs. But teams that want to improve their skills & capabilities (so as a result - enable new technical capabilities to build better products) usually have some reconnaissance in force running.
Hedge as default
The technology you hedge with has to be battle-proven - it can't be just theoretical option that hasn't been tried & will have to be grokked from scratch if needed. Quite the contrary - some teams hedge tech by using at least 2 very different tools to do similar tasks in the same time - each of them covering ~50% of needs. It could be:
- ASP.NET MVC & Gin - to build Web APIs
- Ember.js & React+Redux - to build JS apps
- Redis & Hazelcast - to build simple, distributed in-memory data store
- etc.
Not only about tech
Hedging is not only needed due to tech issue-related risks - consider other risks related to potential vendor/product lock-in. Things are happening - sometimes licensing terms may become unacceptable, royalties may raise above affordability threshold, supporting company may go out of business or community may lose its interest & deteriorate. Having a different option(s) on the table, a one that will enable you to proceed with a full speed since the switch-over decision moment is a big advantage.
The whole idea may seem odd, especially because it's against typical enterprise approach to unify tools & practices (for the sake of lower TCO) - unfortunately this approach quite frequently ends with treating all challenges as nails, because all you have as a tool is a hammer ...
Personally, I've never heard it named like that ("hedging technology") before, but I am all for. For one basic reason - there's no perfect technology & even some very good ones have their ups & downs. It means that we're never make perfect choices that will cover all future needs as well, so it's normal that under some circumstances we shouldn't stick to the path once chosen like there's nothing else under the sun. That's why I believe that keeping the ability to easily (& quickly) switch-over to fallback option(s) even if it means different platform, language, framework is far more important than very narrow in-depth specialization in what we're currently using.
Pic: © dp@pic - Fotolia.com
