Choosing your tech stack for new projects can range in difficulty depending on how many variables you have to consider. It can also vary depending on what kind of company you're in. Are you an agency that specializes in marketing sites? You probably already have a favorite PHP framework that you can leverage. Are you a start-up company that is building a revolutionary product from the ground up? You have the freedom and flexibility to try new experimental technologies that can give you an edge in the market. Are you at a massive enterprise company with several thousand employees around the globe? Your technology choices will probably be determined by existing skills and timelines. No matter which situation you find yourself in, I strongly recommend that you think about the people who will actually build it. Focusing on the actual delivery team will keep you rooted in reality. They're not just bullet points on a slide deck for the executive team, they're real humans with their own wants and needs. Let's take a look at some counterintuitive thought exercises to help you make the right decisions.
1. What Does My Team Already Know?
If it ain't broke, don't fix it. If your team is already well-versed in React and Node applications, why switch to Vue or Java? In most cases, you'll have multiple options of technologies that do mostly the same thing. In these cases, it's important to lean into what your team is already good at. The cost of learning new frameworks and technologies is expensive and risky. Sticking with a single technology can also increase your ability to scale because you can cross-train resources. If every project has different tech stacks, the knowledge transfer process becomes insurmountable very fast. Developers can't know everything. In order to get really good at something you have to spend a long time doing it. That experience can usually transfer at the conceptual level but not at the syntactical level. These things slow you down and create frustration on your team. Unless you have a definitive reason why you must use a new tech stack for a project or an extremely long timeline that would facilitate the learning process, it's usually best to stick with what you're already good at.
2. What Does My Team Need To Learn?
Lack of growth makes people quit. If you're not helping your team learn new skills and solve new problems, most of them will eventually get bored and leave. In today's technical landscape things move very quickly. If your team isn't able to adapt and integrate with new technologies and tools, your clients and customers will know. Developers are usually very tapped into the evolving market as well. They have recruiters hitting them up on LinkedIn with new offers, new blog posts celebrating evolving tech, and multiple content creators who make a living off building hype for new technologies. The software development educational industry is actually kind of predatory actually but that's a topic for another article. Tutorial Hell is a real problem though. That said, attrition and talent acquisition are often overlooked when it comes to technical conversations. This is a mistake. It's also a great segue into our next question!
3. What Does The Market Want?
As much as I hate to admit it, recruiters have the power to drive trends in the industry . Developers are smart. If they see the same technology over and over in job descriptions, they will take note. The market determines your worth based on the value you can provide. This happens in the short term and the long term. The best example of rapid change is JavaScript. The JS market is about as volatile as the crypto market. There's a new "hot framework" released almost every week that revolutionizes the role of JavaScript developers. This means that developers who use that language are constantly learning new things and more importantly are expected to learn new things rapidly. Becoming an expert in the wrong SPA framework for too long can literally make or break your career.
In contrast, we can look at COBOL developers. Roughly 40 years ago that language was very popular. Then it took a nose-dive into the tech graveyard as newer technologies were adopted. This led to a massive shift in what developers learned. Supply and demand. If there's no demand for your skills, the value of those skills will fall. Then developers will stop learning those skills. However, that's not how the story ended. A few decades later everyone suddenly realized that there were still COBOL applications in use! We suddenly saw a massive demand for these skills and there was almost no one who knew them. This flipped the supply and demand on its head. Being a COBOL developer today might mean very high paychecks and little competition. What the market wants, the market gets... eventually.
Conclusion
At first glance, some of these questions seem to contradict each other. However, if you dig deeper you will see that contradiction can be a good thing. These questions are thought exercises to help you weigh the pros and cons of different technology choices. Choosing the wrong technology can destroy timelines, create massive technical debt, and cause attrition on your team. The stakes couldn't be higher in most new engagements. In those tense moments with new clients or when creating a new start-up, take some time with your counterparts and make an intentional decision. Most of the time you won't know if the decision was right until the project is over. The good news is that software is "soft"! This means if you did make the wrong decision at first there is always a back door where you and the team could potentially migrate pieces over to new technologies that are more well-suited to the task. This is not an easy task but it can be done! The point is to be intentional about your choices, document your reasons, and review those assumptions as the project hits different milestones. If you continually do that, you and your team will always be moving forward!