I am currently going through a process at work to choose a new software tool. I once read an article on HN that described well how to best make a decision on what product to pick and not fall for things like comparisons using feature matrices - however I can't find it. Does anyone have any good links to such articles?<p>Example decisions are: MySQL vs Postgres, GitLab vs GitHub, Ubuntu vs RedHat
Let's pretend you are building a typical CRUD web application with medium level of expected traffic, some kind of SaaS. You could build it with MySQL, Ubuntu, using Gitlab for source control and pick a web framework - Laravel, Rails, Django, etc. And that could be successful. Or you could pick Postgres, Redhat and Github with whatever web framework and that could be successful. Pure technical decisions are usually better off going with what people are most familiar/knowledgeable with assuming those are mainstream supported technologies.<p>An important aspect is the cost or ease of switching to something else later on - the impact of the decision itself. Switching out your hosted git provider is probably easy, maybe a day of downtime. Switching out databases once you have users on the system would be a major project, maybe 3-6 months. Changing out web frameworks in the example SaaS could be an entire re-write.<p>If you need to present your findings to some management layer to get them onboard then you may want to get a sense of what they're thinking (i.e. does someone really like XYZ?) so you can focus efforts appropriately. Gathering info on non-functional aspects (cost, support, license model, etc.) will go a long way towards them evaluating the decision if they are non technical.
The chances are that either solution would work.<p>Generally I find thinks like this are chosen depending on:<p>1. What other products are in use in your org / team
2. What is the general direction of travel for products in your org/team
3. What is the cost to the org for any licenses / supported versions you want to implement
4. What backhanders / perks / relationships with friends are involved with the management / purchasing team<p>If you haven't built anything yet, I'd strongly recommend you start building with something you have knowledge of that is commonly and widely adopted in the industry and then refactor as you find you have issues or particular requirements.
Evaluate pros and cons. Don't just talk about them, write them all down.<p>Try to be specific with your use cases. Don't write pro of a mysql "Can be used on any shared PHP hosting" if you know you are going to have complex deploys in AWS.<p>At the end it should be fairly obvious just looking at the document.
why the prejudice against "feature matrices" ?
In all my professional experience, nothing beats a six-sigma-like "Weighted Decision Matrix" for such choices ( and explaining later on the "whys" )<p><a href="https://www.fool.com/the-blueprint/weighted-scoring-model/" rel="nofollow">https://www.fool.com/the-blueprint/weighted-scoring-model/</a>