Frequently I come across questions in the format:

Which <tech> is best?

Whereas <tech> could be a:

• game engine
• 3d modeling software
• hardware (mobile device, computer, VR headset, sensor)
• programming framework/library
• software architecture or algorithm choice
• asset store
• etc.

And the answer always is …

It depends! 🙂

Generally speaking, “best” is very subjective. What you really should be asking is this:

Which tech is best in the context of my development project?

At a minimum, mention how you plan on using the tech and what kind of project you are working on and any essential requirements.

Omitting context when asking a “what is best?” question will, at best, result in useless advice. Sometimes it may be downright bad advice, because unspecific recommendations tend to bring up only popular solutions and personal favourites – while probably good solutions those may be totally unfit for your purpose!

For instance, the solution may not support the one feature you require. Or the tech is not working on all targeted platforms. Or it is incompatible with other software you are using. Or it is prohibitively expensive. Or it must not be used due to its copyleft license.

Therefore, the more context you include in your question, the better the answers will reflect your actual need!

How to decide on a tech?

First, consider if the technology you require is mission critical.

If it is, the advice is not to take one solution and go with it but rather review several, if not all!

Make a list of features that the solution is absolutely required to have. Then check on the websites and in the documentation which of the solutions satisfy all requirements. Discard any solution the moment you realize it doesn’t satisfy just one of your essential requirements.

In case none of the solutions satisfies all of your requirements don’t hesitate to question your initial requirements. Perhaps you are asking for the impossible? Or maybe some requirements aren’t truly essential? You may have to compromise.

Then pick the solutions that satisfy all criteria, download and install them. Make good use of the trial period or refund policy for each solution. Be sure to have plenty of time available during the trial period. Sometimes it’s best to trial one solution at a time to stay focused and make best use of a short trial period.

If the tech isn’t mission critical however, you should be safe using the first solution that seems to do the job and move on. Decide mainly on ease of use, documentation and support – not promises!

One should avoid analysis paralysis in general, but even more so when the choice doesn’t actually matter. 😉