Introduction
When you are making software as a team, or on your own, you know you can't make everything yourself. There are plenty of people working hard on something you might be able to use.
Sometimes the number of solutions for 1 challenge you're facing, are available in large amounts, sometimes there's only one. How do you know which solution to select? (The apples and pears dilemma.)
The scorecard
It is always a bit of a puzzle, so I tend to make a scorecard to give me a better idea. Points (1-10) are given to particular data. Depending on what you think is important for a solution, you can use a weighted scoring system.
You totalise the outcome and now you can compare.
Even if you only have 1 solution, if you do this every time, it gives you a rough idea how useful the solution is for you, and if another one appears on the horizon, it's easy to compare later on.
My scoring list
- Popularity
- Age
- Stability/regular updates/clear releases
- Roadmap
- Documentation
- examples present?
- Does it seem trustworthy?
- Other publications present?
- Open issues
- look at age too
- average time to react/solve
- are beginner questions anwered quickly?
- Latest version
- checkout and find out testcoverage
- do your regular linting
- review code
- Questions/answers on fora (stackoverflow/reddit/...)
- are there a lot of unanswered questions?
- Micro-version
- use it in a small program in how you would need it
- is it easy to use?
Adapter, when in doubt
Often I see myself looking at several potential solutions which are strong candidates. Or I see a newcomer around the corner, which is tempting to try out. Or you find out that the solution isn't that trustworthy anymore.
Most of the time, I find myself making use of the Adapter pattern, which means that my software doesn't need to change if I decide to change a solution. The advantage is that if I choose a solution now, but later on there's a better one, fast one, simpler one, you name it, I can always switch without to much of a hassle.
Top comments (0)