As technologists, we often get ahead of ourselves. I know more than once I’ve fallen victim to chasing after the latest, hot, sexy technology and finding out how to integrate into my development as fast as possible, often before it was really ready for it. For me these have included Ruby on Rails, Docker, Google Compute Engine, MongoDB, and CouchDB just to name a few. Most of the time it’s a fleeting flirtation, your eye captured by its beautiful curves, shiny exterior and promises to solve all your woes. But as soon as you scratch the surface you start to see the flaws. More often than not, what you were promised isn’t exactly what you’re getting, and often the cons outweigh the pros. Code examples? Limited at best. Have a problem that’s even remotely unique? It could be you, it could be a bug, but either way there is probably very little documentation on it and its on you to figure it out.
On rare occasions though, you can get a sexy new development partner to whisk off to Rome in the spring and ride camels through Petra with. A technology so great that its worth the extra time learning it, so useful it actually solves your problem without opening a new bag of worms, a tool that will quickly become an essential part of your technology stack.
But how do you if you’re ready for this? This is often a long-term relationship if you commit to it, one that’s hard to back out of. And with any relationship, you first have to be in the position to commit.
Is time going to be a big constraint on the project?
If the answer is yes, stick to what you know. More likely than not, unforeseen issues will arise that will leave you battling this new technology and trying to get your project out the door. Timelines are always tight, while even if you test the technology and it works in a test project-you’re more than likely building something far more complex and there will be little documentation and potential edge cases that you’ll be the first one to hit.
Skunkworks or $$ Making Production?
Do you actually depend on this working? If it fails, even for a few minutes, what’s the cost? Can you stomach it?
Now if you have the time, and can stomach the cost, let’s take a look at the technology you want to implement.
If this doesn’t work, will it be easy to remove?
How interwoven would this technology be into your system? If its something like using a new database, switching could mean using a new DB connector, a new ORM, and performing a costly and potentially error-prone migration.
How’s the community?
Even if it’s new and there’s not a lot of documentation out there, there should still be maintainers of the project available either via listserv, IRC, StackOverflow, or similar way to get in touch. Don’t expect them to do all the work for you, but if you properly debug and give them the right information, they are normally more than happy to figure out how to fix it for your (broken) use case.
What is it replacing?
What’s the gain? Do you want to just use it because it’s cool? You need to have a good reason for adding it. You should either be replacing something or gaining a noticeable improvement in speed/maintainability/functionality. Just because it’s new doesn’t mean its better. You also need to make sure that you actually need the gain. Switching your web server to one with a lower memory footprint? That’s great, but probably not useful when your application is CPU-Bound.
And that’s it, that’s the framework I use when I evaluate how/when to use the latest new technology. Use your best judgement and don’t be afraid of being conservative-an app that ships is infinitely more useful than one that doesn’t.