I have heard folks say that they are not “innovating” at work. When I ask them what that means, often they will tell me that “old technology” reigns at work. I can tell you, as the owner of a ‘62 VW, that newer is not always better. Newer has some advantages, certainly: fuel efficiency and speed among them; however it also comes at the cost of complexity. Whether it’s worth the trade-off will depend on your situation, the primary point is that it is not implicitly better.
Don’t underestimate old technology
Old technology, such as my air-cooled ‘62 VW, are still around because they work. Certainly they’re not the latest-and-greatest but they are predictable in their behavior. When you are building software that has to run 24 hours a day, 7 days a week you want things that you understand. If you were a delivery driver, would you want a VW van, something that is relatively cheap and easy to repair, or a Ferrari? Most business owners, I think, would choose reliability over glamor because it’s what pays the bills. Shiny cars do not pay bills, they cause problems.
In a similar fashion, there is a lot of boring software that just works – sure it may be a bit of work to compile some new piece of software on RHEL 5.x but RHEL 5.x has a long-term support expectation and will continue to be maintained in a way that not many other distributions will. Older technology has a wide audience of users and has been explored to great depths by a lot of people. Does this mean that old technology is always the answer? Well, no; but it is certainly has a lot of people you can ask questions of when things do go wrong.
Databases, such as PostgreSQL, are “old” and “boring” and “crusty”. But you know what else they are? They’re fast at what they do and they’re exceedingly reliable. Craigslist uses MySQL behind the scenes to power it’s high-traffic website. In fact, the entire site is built using MySQL and Perl both of which are (by today’s standards) ancient dinosaurs. Amazon’s internal deployment tools, which manage millions of hosts and perform millions of deployments per week, are powered by a combination of C++, Java, Perl and Oracle databases. And you know what? They work; and they work well.
“I’ve never had a problem with {insert hot new technology here}” –Nobody, ever.
Don’t place too much stock in the new-hotness
For example, consider the 1991 Volkswagen Corrado; an incredibly fast, super-charged inline 4-cylinder sport coupe. It was incredibly desirable at its inception - hand-built, superb handling, and also a complete nightmare of maintenance. I should know, I have (perhaps foolishly) owned three different Corrados over the years. Given a reasonably short period of time almost everything failed on those cars from mechanical malfunctions to electrical gremlins, each time in new and spectacular ways. There are countless recalls on those cars including failed heater cores and a whole host of other issues.
Story time
When I worked at UpCity I decided that we should use Riak to store our ranking data. Why not? It is horizontally scalable, it was new and exciting, and it was all the rage. Was it a good decision? In the long run, yes, it was – it provided us with a data storage mechanism that better suited the data we were storing and it permitted us to grow with our data. But it brought along with it a learning curve, from learning how to manage it in production, to performance tuning, to figuring out how to issue MapReduce queries to it, and so on.
Does this mean that CrazyAwesomeNoSQLStorage 0.4.x is not worth investigating? Of course not! There may be a number of problems that it solves for you, but remember that for every piece of new technology you take on you are also committing to making a number of mistakes at the beginning. To think otherwise would be a mistake; nobody gets things perfect the first time they try and so there will be some amount of throw-away work and some additional overhead with respect to operational burden.
Spend your resources wisely
With every new technology you have to master takes away time you could spend building a new feature, reducing technical debt or enhancing existing functionality. Every team has a finite set of resources and they need to allocate those resources in a way that makes sense to achieve their goals. That doesn’t mean that new technology is always removed from those goals, it simply means that it’s something to consider when thinking about adopting a new technology.
MongoDB was the new and exciting NoSQL data storage engine earlier this decade and look how it’s burned folks