Choosing the right technology stack is half art and half science. Getting that balance wrong can have a significant impact on your project, so it’s crucial to assess all possible risks. Here are the seven big questions to ask before adding a new technology to the mix.
1. What does the talent landscape for the technology look like?
The most common question I get from clients is whether they’re going to be able to easily find another developer who knows the technology stack. I always suggest they start by looking at how common the skills are — a tip is to use sites like Indeed’s Job Trends to see how many job postings list those skills.
2. What is the culture around the technology?
3. Who’s backing the technology, and why?
One of the best ways to determine a technology’s risk is looking at who’s responsible for managing and developing the technology. Microsoft backs .NET, Apple backs Swift, and Facebook backs React. And then there’s the best-case scenario: technologies like Node.js that are backed by nonprofit organizations.
A corporate backer isn’t necessarily a bad thing. Just make sure it’s in the backer’s best interest to do what you want. Because Microsoft makes money selling Visual Studio to .NET developers, it’s likely to keep .NET an attractive option so it can sell more tools. Then there’s Facebook. It doesn’t sell tools around React Native, so if React Native stops being valuable for recruiting developers, Facebook could easily cut its support. Minimize risk by choosing a technology with either a nonprofit backer or a corporation that has a financial stake in the technology’s success.
Whatever you do, make sure your technology stack is open source. Closed-source technology platforms just aren’t taken seriously.
4. How mature is the developer tooling?
Think of technology the way you think of the iPhone. It took about three versions to really get it right. Software stacks work the same way. The earlier a technology is in its lifecycle, the less reliable it’s going to be. Ruby on Rails has gone through several years of iterations, so it’s low risk. Rust, however, might be right for certain tasks, but it’s still maturing. Thoughtworks’ Technology Radar is a great tool for exploring where different technologies are on this curve.
It’s not just about making sure the technology is built to last. Mature technologies also have a full ecosystem of tools. Continuous integration, code analysis, bug tracking, all these tools make developing easier — and they only exist for technology stacks with a full market of developers.
The proliferation of those tools indicates how safe a bet the technology is. .NET is the Cadillac of development languages. It has leather seats, all the options, everything. Then there’s Node.js, which is a bare-bones Jeep — it doesn’t even come with doors. One’s not inherently better than the other; it’s all about the experience that best suits your business.
5. How easy is it to build and share solutions?
Maturity can also mean a great suite of third-party packages, or community-generated code that handles certain tasks. This makes development quicker, because programmers can find a ready-made solution. With almost 300,000 third-party packages in the NPM ecosystem, Node.js has the biggest package ecosystem across any technology, because it’s so easy to build and share things. It makes Node.js more likely to last, since developers will be drawn to a technology that has a full suite of easy-to-use solutions.
6. What are the maintenance needs?
Every technology requires basic hygiene. When you’re thinking about the costs, don’t think just about the build, but all the costs that will go into managing a solution over time. Technologies like WordPress do a lot of work to make updating easy. Others, not so much, especially when a significant amount of customization has been done.
Find out how the backer of the technology handles security issues and how often it pushes updates to get a sense of the resources it’ll take to keep things up-to-date. The last thing you want is an outdated version that leaves you vulnerable to security threats, so pick a technology with a maintenance process your business can handle.
7. What are the technology dependencies?
Most technologies build upon one another. Take Ruby on Rails: Rails is a framework that relies on Ruby, making it a secondary technology. To know the risk of Rails, you have to also know the risk of Ruby. And primary technologies like Ruby have dependencies, too. You want to make sure each link in the chain is strong, and that links can be replaced should something go wrong.
The Heartbleed bug is a perfect example of how one weak link can take everything down. It was caused by a broken component in a library called OpenSSL — which happened to be one of the most widely used cryptographic libraries. When the Heartbleed bug was introduced, every technology that relied on OpenSSL was vulnerable.
To choose your technology stack wisely, ask these seven questions not just of your main technology, but of every technology it depends on, until you’re sure you have a chain that can support your business.