Factors to consider in choosing a tech stack for a project

It's not as complicated as it looks... Sometimes.

Tuesday 30 July 2024

In the middle of writing a rant and a half (thanks, Twitch chat), I ended up with a list. That list kept growing, so it’s now its own article instead.

Below is a non-exhaustive list of things I consider when picking a tech stack for a project. The weighting of all of these differs between projects. What I’m looking for is:

• How flexible is the stack?
• Where does customisation to the project happen?
• How will the piece of tech affect the wider workflow and pipeline it’s a part of?

The list

Team presence

Teams are a double-edged sword; sometimes decisions are made for us, and at other times are a minefield of opinions. Often we’ll need to take everyone else’s (everyone relevant 🫥) strengths and views into consideration.

Performance

• Why does it perform well?
• Where are the bottlenecks?
• How does it perform at scale (not just for a li’l starter repo)?
• How is the tech managed at scale?
• How does this piece of tech compare to other similar pieces of tech?

Benchmarks

There are many different benchmarks. You’ll have to look and consider the relevant ones for your use cases.

• How are the tests performed?
• Are the tests standardised, and appropriate?
• Are they updated?

Security

• Are there any massive vulnerabilities?
• Are there special features to address security concerns?

Developer experience

• Is this a test of spiritual endurance, or will I be mentally frolicking through a meadow?
• Are there features I appreciate?

People have varying opinions on these —  just take a look at the CLI- vs GUI-based crowds. If you prefer GUI tools just be prepared for someone, somewhere, who won’t take you seriously as a developer.

Replaceability (of me!)

Aside from being convenient for my employers, what about me (yes I am definitely making everything about me here)?

• Should I want to leave, will my employers find a replacement quickly?

Side note: There’s no need to fabricate a situation where one can’t be fired by using more complicated tech. Do good work, be a good employee, and they won’t want to fire you. It’s not like you work in DevRel.

Maintenance

• How difficult is it to maintain a project once it’s ‘completed’ by me or others?

(We know projects never get finished - they’re either maintained or confined to the depths of Davy Jone’s Repo).

Compatibility/integration

• How compatible is the tech with any existing tech or tooling?
• How does the tech integrate with other tech we’re looking at in the stack (especially for testing)?
• How seamless is the integration process?

Ecosystem and support

In my case, if I’m picking a new technology, I’ll need either solid documentation or a community to badger if the documentation is sub-par, which is often the case.

• How strong is the community surrounding the tech?
• How responsive are they?
• How many plugins/tools have been made available for development?
• How easily readable are the docs?

Speed of building

Believe it or not, not everything has to be built ASAP. There are tradeoffs for everything - if there’s time to learn tech to use the right tool for the job, that is preferable.

• Does this need to be really quick?
• If so, is the level of familiarity important?
• Is generating income quickly (or a deadline) from the product factoring into my decisions?
• If there’s the added difficulty of adding certain features without any existing plugins or libraries to make it quicker, how will that affect the time to implement?
• How steep is the learning curve?
• Will I need to purchase training?

Cost

• What costs and resources will be affected when it comes to building?

Future-Proofing

Using outdated tech can hurt projects.

• Is this technology ‘future-proof’?
• How frequently is the tech being updated i.e., will it become obsolete soon, especially at risk of security updates or clashing as a dependency?

Vendor Lock-In

Not always a bad thing… But usually not preferable.

• Is there a risk of vendor lock-in?
• How easy is it to switch to a different technology if needed?

Compliance/regulations

Who knew laws are a thing?

• Are there any compliance and regulatory requirements to consider?
• Does the technology meet industry standards and regulations?

Whew!

That was long. Congrats and condolences on making it this far. What else do you look for?

Perhaps I should make this into a checklist as a part of a website funnel, eh? “20 things to look for when you start a project - just enter your email below”. Too bad I don’t care.

Good luck with your projects!

Share on