In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Tip: It’s a good idea to pre-prepare a bunch of post-its with common or more obvious functional requirements beforehand, then add to that list as you go.
Feel free to delve into the rabbit warrens when they arrive. If your pre-prepared requirement says: “users should be able to log in”, interrogate that a little further; start asking questions about roles and permissions, about how many users you may have, and how many concurrent users need to access the system. You may uncover some interesting assumptions from within in the group.
Open source software is fabulous, but not always right for every project. For some systems, relying on a tried and tested paid solution may well be more appropriate. Depending on the non-functional requirements you previously gathered, uptime SLA’s, and guaranteed support might be more important than price.
Some software has upfront costs, some has monthly or annual subscriptions. Sub-sections of the system may also have their own costs; plugins, add-ons and transaction fees come to mind.
If you are relying on open source software, strongly consider donating back, it helps keeps the authors in business, and in-turn, working on the project that powers your system.
There are always risks to consider when making a tech stack decision. We joke about there being a “new JS framework every week”, but the age of the product may well be a deciding factor. Too new and you could encounter teething problems, too old and you run the risk of the project being discontinued, or support being challenging to find.
The ecosystem and community of the solution should also be considered. If there is a healthy community of supporters, maintainers, and authors, the risk of project discontinuation is reduced. It will also be easier to find external support when required.
Finally, you need to consider your own experience. In our most recent case of picking a CMS, it might’ve been that a system written in Java was the most appropriate, but if no-one on the team has experience in that language, or your hosting infrastructure doesn’t allow for it, that’s a huge risk to undertake.
Exercise: list your solutions
Start gathering a list of the possible solutions. Go as wide as you can and include a few wild cards, even if they feel totally inappropriate, they may well surprise you. It’s worth asking your network, colleagues and on Twitter. The more options you have to profile, the better.
Main exercise: Ranking spreadsheet
It’s time to start ranking our solutions against our requirements. We like to use a Google Sheet for this sort of thing, but feel free to use Airtable or a simple piece of paper!
To help you along, we’ve created a Google Sheets template that you can use to get you started.
Along the top, we list our solutions, and down the side our requirements, costs and risks:
In the world of software development, anything is technically possible given the right time, budget and team. A simple boolean yes/no isn’t a fair assessment when profiling systems against functional requirements. We need a more nuanced profile, and go for a 5-point scale:
- -2: Incredibly complex or time consuming to fulfil
- -1: Complex to fulfil, requiring a lot of custom code
- 0: Possible, but would require custom coding
- 1: Achievable, perhaps adapting an existing system feature
- 2: Very achievable, and available out of the box
The same -2 to 2 scale can be used for non-functional requirements too.
Work through each system, one at a time, ranking it against the requirement. Bring up the project documentation as you go - it’s a great way to get a flavour of how well written their supporting information is, should you choose that solution.
Try to be as objective as possible when scoring. By breaking out each project feature into requirements, we’re trying to reduce our overall and individual bias.
For costs, work out the year one and two costs. It’s good to be as aware of the ongoing costs as it is the upfront ones. Factor in plugins, add-ons, donations, maintenance and hosting. You may find it helpful to also break it down to monthly figures, if that will aid stakeholder buy-in. Once you’ve completed the cost breakdown for all the solutions, rank them accordingly working from 0 down. In a group of ten solutions, the cheapest should score: 0, and the most expensive: -9.
Risks are subjective, and in some ways they should be. Consider age of solution, ecosystem and experience, and rank them from 0 and down.
Once you’ve completed all the ranking, it’s time to tally up the results.
Non-functional requirement multipliers
Using the earlier results from the ranking exercise, reverse the order to work out the multiplier. The most important requirements will have the largest number, going down the least important with a multiplier of 1. If you ranked some requirements equally, keep their multipliers the same. You’ll end up with a list a bit like this:
- Usability × 6
- Accessibility × 6
- Security × 5
- Reliability × 5
- Maintainability × 5
- Recoverability × 4
- Environmental × 4
- Affordability × 4
- Performance × 4
- Availability × 3
- Interoperability × 3
- Regulatory × 2
- Capacity × 2
- Manageability × 1
- Scalability × 1
- Data Integrity × 1
- Locality × 1
To amplify the most important requirements, we multiply each score by its position in the scale. A solution that scores negatively on one of the higher priority non-functional requirements, like usability, will therefore take a larger hit than one that isn’t hugely scalable.
Functional requirement multipliers
We can use a similar multiplier for functional requirements:
- Must have × 3
- Should have × 2
- Could have × 1
Cost and risk multipliers
Multiply the final scores for each solution by 2.
Adding up the totals from the four requirements section should give you a score for each possible solution. Sort the solutions in a descending order, where the highest score is the most appropriate option.
If some of the results seem wildly off, double-check your multipliers, it may be for your project that costs should be multiplied by 4, rather than 2. There’s no one-size-fits-all approach here.
We then wrote a few paragraphs for the following sections:
- The main contenders (top 3-4)
- The middle of the pack
- The inappropriate options (bottom 3-4)
Explaining why the solutions were more or less appropriate is incredibly important for when you present these findings back to less technical stakeholders. Don’t skip this step, we found the act of synthesising and writing up the results to be a hugely useful part of the process.
The results should by no means be viewed as conclusive, but should help frame a discussion about the various options, and might just pull a few surprise options into consideration - it certainly did for us.
This was originally posted on my website.