There is a staggering amount of new technology out there. In their last report, GitHub claimed they had 19.4 million repositories. Netflix alone has 124 projects in GitHub. With all these new projects out there, it’s tempting to try and use it all. But you must resist.
The lure of the shiny new thing can be hard to resist. Many of us got into software development because we were curious about how something worked. It’s only natural to want to play with that cool new thing over there.
But it’s one thing to play with a new technology. It’s quite another to integrate it into your production systems. Be careful what you actually integrate into your technology stack. It may not solve your problem, there’s a cost to integrating it, and you may just be trading one set of problems for another.
Solution in Search of a Problem
When you choose to use a new technology, stop and think about whether it actually solves a problem you have. You may think that new Whatzit Classifier is neat, but if you don’t actually need to classify Whatzits, the tool is really more of a curiosity.
Does the technology solve a problem you’re working on, or solve it better than something you already have? If so, give it a look and evaluate it. But consider the cost of doing so.
There’s almost always a cost to integrating a new technology. It takes time to learn how to use it. Time to integrate it with your existing code. There’s the testing time and the time spent tuning the configuration. Don’t forget the time and effort to install and maintain it. If you can’t make some kind of case for the return on investment (ROI) it may not be worth the effort.
Technology Overload
One cost that is often overlooked is the cost of onboarding new developers. Each time you add a new technology to your stack, that becomes one more thing that new developers have to learn. That complexity translates into a longer ramp-up time to become effective.
The problem is even worse if you have multiple technologies that solve the same problem. How do the more junior developers know when to use Kafka versus Rabbit MQ? MongoDB or Postgres? There may be good reasons for having both in your stack, but you’ll need to have good guidelines to help ensure they’re used properly. Otherwise, you’re better off sticking with a handful of systems until you find a reason to branch out.
Trading Problems
Maybe you’re sick and tired of the technology you’re currently using. The color glossy brochure for that thing over there makes it look like a dream to work with! But as the saying goes, the grass isn’t always greener on the other side. Nearly every technology has some warts. Are you really willing to trade the problems you know for the problems you don’t know?
In addition, newer projects may not be as mature. Have they been battle tested in production systems? Is there good support, either from the community or commercially? The problems you need to work around are not usually evident until you’re deeply invested in the technology.
Technology is Good
I’m not suggesting that you should shun all new technology, live in a cave and write all your code in assembly language. These various systems and libraries solve real problems for real developers. Read about them to your heart’s content. Play with it in sample or personal projects. File that knowledge away for later use. When you have a problem to solve, by all means, see if the new thing solves that problem faster and cheaper than what you could write yourself.
There’s a lot of neat stuff out there. Make sure you’re using it because it solves a legitimate problem, not because it simply looks interest….squirrel!