How to Choose Technology
In a complex, fast-paced landscape with constantly shifting goalposts and endless choice it can be tricky to decide on tech and even tricker to be confident you've made the right choice
There’s nothing like that feeling of starting a greenfield project. No technical debt, and free-reign over your fiefdom. You can literally choose ANY technology you want… well, in theory.
You could build in any Turing-complete language, but that might take the kind of extra-time a commercial or public project simply could not justify.
Even if you could justify the extra time/cost, a project could have trouble finding support in the community, finding other developers who understand an approach, or willing to take the time to understand it.
What if it could be justified? What if you have very specific requirements, like keeping the source code as obfuscated as possible for security reasons, or performance requirements which outweighed all else? These reasons could easily tip the scales toward unconventional choices, which are practically justified.
It’s easy to criticize tech choice after it’s made. Let’s take a moment to remember the idea behind survivorship bias. Looking at current projects and critiquing its weaknesses is akin to looking at the bullet hole patterns on returning war planes and deciding that’s where armour reinforcements should go.
The better way to look at the situation is “This software exists today because it adds more value than it detracts” or “This plane came back full of bullet holes, but damage was in areas it could withstand, that’s why it’s here.”
The planes that didn’t come back from battle are the ones that need better armour placement.
That’s not to say we shouldn’t be constantly improving, and assessing problems, issues and weaknesses in design.
The reality is; if you move the needle in any direction, you move it away from some other vector due to implicit tradeoffs.
The only way to resolve this contention; honestly understand your own values in order to match them against the virtues (and inversely, weaknesses) of a given technology.
If you need something out the door next week - that rapid prototyping framework is going to be the only thing to achieve it.
If you need something with a full enterprise support contract - well that narrows down your choices a great deal.
The challenge is when business priorities and values tend to change more rapidly than software can possibly change, after it’s deployed. Our entrenched choices are easily questionable. Survivorship bias reminds us that this is a good problem to have. It means we succeeded!
So how can we characterize ourselves and our landscape to make things fit?
What’s our profile?
Experience of the team - Do we have a lot of senior people who can adapt and learn quickly?
Hiring strategy - Do we have enough developers, or are we intending to hire more soon? Budgets & talent availability vary for different languages and frameworks.
Language experience - Does the team/company have existing standards which it wants to uphold? Do the team members feel more confident with one language over another?
Risk profile - Is this a startup, a skunkworks project or a large company? What industry? Large banking tends to have more at stake than small startups.
Budgets - Perhaps you can afford to pay for a support contract?
Security considerations - Perhaps using a technology owned by a particular nation-state is totally off limits for a government project.
Once we understand our own profile and values we can hope to match those against the range of available choices.
Vectors to consider amongst choice candidates:
Vendor-lock - If we use this software, how locked-in do we become? Are the purveyors of this software also the owners of an underlying platform which could otherwise be agnostic?
Cost / licensing - Is this free software? Will it always be free? What assurances do we have? Should we be suspect of the business behind it looking to eventually turn a profit?
Maturity / age - How long has this technology been around? How stable is it? What does the community and support model look like?
Popularity - How hard is it to find developers now and into the future, and what will they cost?
Logical pitfalls
Here are some common examples of ideas or arguments which are either cyclical or don’t hold up against realistic values.
“NodeJS is great because it runs your server automatically and also it means the front-end and back-end of your application are written in the same language”
While it’s true that NodeJS is it’s own web server - and this may save time and make things quicker to bootstrap initially, this reality also incurs security, stability and usability concerns, which could easily invalidate the positives.
Sure the same language is being used in the browser and the server - but the practical reality is that the frameworks used for Single Page Applications and for NodeJS back-ends are totally different, and the problem domains are different, which negates a lot of this perceived value.
“Kubernetes is a solid choice to run our application because It’s the new industry standard for containerized workloads”
K8s is marvellously capable, and also very complex. It’s likely easier to get wrong than get right, so benefits and capabilities need to justify its costs and risks. Just because It’s the shiny-new-thing doesn’t mean we should adopt it immediately.
“Pulumi is a great choice to deploy infra because it allows for any language rather than a strict DSL with limited flexibility”
It’s true that Pulumi works across cloud vendors, is language agnostic and allows for elegant programming patterns. However these are only real advantages if they match up with our values. E.g, you have a small cloud-native project with a limited number of resources not requiring advanced variability - Terraform or CloudFormation could be more appropriate choices, since they give you what you really need much faster.
ADR’s to the rescue
No matter what we choose today, we will be entrenched with our decision tomorrow. There is no perfect choice, and making some choice over no choice is decidedly better.
The long winded discussions we have amongst team members and deep-dives into research and testing are usually long forgotten by the time someone comes along and asks something to the tune of:
“Why’d you choose THIS tool rather than THAT tool?”
ADR.md https://adr.github.io/ Check the ADR!
Architecture Decision Records are a great way to document project design choices in a decision log along with their rationale and supporting evidence from the time of the choice.
If nothing else, this helps future developers understand the technology landscape at the time of the choice. Things have likely changed since then, so context like “Technology X was in its infancy at v0.1.2 so we rolled our own” gives people some historical context to what may otherwise seem arbitrary o unconsidered.
Key Takeaways
Focus less on the technology choice and more on problem space
Understand the overall values of your industry, customers and company
The right choice at the right time might not look that way in the future. ADR’s are a standardized way of keeping a journal our reasoning. This seems a great choice :)