Today’s Tech Tuesday is a relatively short note on the “Bleeding Edge” — technologies that are even beyond the cutting edge. Every technology tends to start life at the bleeding edge with early releases that are unstable and poorly tested, many different ways of doing something (instead of an agreed upon best way) and with upgrades that are not backward compatible. It is tempting for startups to embrace bleeding edge technology for several reasons: first, you are starting from scratch, so why not use the very latest? Second, if it works out well it can give you a competitive advantage. Third, it can be a recruiting tool for people who want to get on the next technology trend.
Before you adopt the bleeding edge though, make sure you understand the downsides. In the worst case scenario you find yourself sitting on technology that is no longer supported at all. That will leave you with a tough decision between maintaining it yourself or migrating away. Even in the best case though you are likely to face changes that come from the external technology that force you to rewrite your code (because the changes are not backward compatible). There too you face a tough choice — if you stop upgrading you avoid any rewrite but in all likelihood you are not stuck with whatever version you have which at some point (often very soon) will no longer be maintained.
As a general rule then I suggest to folks that unless you absolutely definitively need it, wait to adopt a technology until it has started to settle down a bit with the vendor (or vendors) reasonably firmly established, the number of releases slowing down considerably and — most importantly — a commitment to avoid backwards incompatible changes unless absolutely necessary. The node.js project for instance seems to be settling down (there are drawbacks to this too as people who were hoping for a different module system were quick to point out), but in terms of adoption this is a big plus.