Not too long ago, I was involved with a new team starting up. The team went through the training and sat at their desks, ready to work on their problem of replacing an existing system. They had a critical decision to make, what would their tech stack be?
This decision plays out over and over, dozens of times in companies. Every new project or product brings the decision back. Every consultancy or agency brings it as well. Building software is a costly decision, and choosing a tech stack has a lot to do with that expense long term.
Choosing a tech stack that winds up being a mistake causes numerous with problems and offers diminishing returns as cost increases. Agencies and consultancies will regularly pick technologies that suit them but aren’t supported by the organization, leaving a maintenance nightmare.
The cost of choosing a tech stack is substantial, but there are several considerations that I bring to the table when groups make this choice. If no one provides criteria, many groups will pick between things that they are comfortable with and things that are attractive. Comfort is great for efficiency, but not forward-thinking. Exciting technology may not be maintainable or survive the rapid pace of change in the industry.
So, here is a list of considerations that I use with teams when they choose a tech stack. This list isn’t some magic formula, but a conversation. The result of the discussion is a decision and a set of likely risks and consequences that the team can manage and bring up with leadership to make sure everything is transparent and managed effectively.
- Are there existing standards for technologies
- What is the team’s current set of strengths and weaknesses
- Is there an expert available when help is needed
- Is there a training/book budget to help shore up weaknesses
- When something goes wrong, or the deadline approaches, how will we get help
- Will the people who maintain this know the technologies
- How long as the technology existed
- What support for that technology exists
- What license, contract, or fees need to review
- Are there outstanding security vulnerabilities
- In 5 years will we be comfortable owning the tech if it is abandoned publicly
- Will this technology scale and perform well today, and if our needs grow 100 fold?
- How fun and easy is the technology to use
- Are there legal, regulatory, or compliance considerations
- How easy is it to upgrade or update
I was working in one team, and the technical director insisted we use a database that they were a fan of. I asked questions about licenses and security as those were relevant to our situation. The director assured me that everything was fine since it was open source. I investigated and found that the license was one that we were unable to use and that the software secretly reported usage back to advertising companies. After some denial that my findings were significant, we spent the next several weeks re-working our system to use a different database.
Another team wanted to use a new front-end framework, and when I asked about resources to teach us and get us through any issues, they shrugged and said it shouldn’t be an issue. In the next two months, our productivity cratered as the team tried to make sense of the new framework by treating it as though it was like the old one, fixing those issues, throwing it all out, and starting over more appropriately.
I have dozens of stories like this where the tech stack decision was made quickly and conveniently, but not thoughtfully. I’ve seen projects abandoned because they don’t have skills in the technology to support it. I’ve seen people quit because the technology change went in a different direction than they wanted. It seems like a small choice, but it has a significant impact.
Next time the decision about tech stack comes up, I suggest slowing down and working through some of the questions I’ve developed. It can save months of re-work, avoid security vulnerabilities, and liability.
I started a newsletter to help developers with their career. Join us!
*image source: unsplash
Top comments (0)