Question

I have a specific use case, and have found 3 ways of doing it across the internet, which are defined for vague usage cases. I am staring at these three wondering which to apply.

I tend to sit there not knowing what to do - then doing nothing... Is there a good way of choosing? Should I try all of them?

To be more specific for some context, I'm trying to make a very lightweight board game where I need a portion of the screen which I can rotate the board game grid, zoom into the grid, and move pieces on this grid. I had no clue how to do this, but I found things online like Core Animation, Core Graphics, Sprite Kit, and I saw arguments for and against them - for example Sprite kit is high level, but keeps the frame rate at 60, which is a waste of battery when nothing is really moving in the screen. Core Animation was a lower level API, which opposes Apple's guidance of "take the highest level of abstraction". I don't want to learn 3 things to use 1. Is there a way I can choose and get unstuck?

I'm leaving this as rather a vague question purposefully as I think it applies throughout the area of software.

Was it helpful?

Solution

You perform a cost/benefit analysis on each of the approaches, and choose the approach that has the highest overall benefit/cost ratio.

In the case of competing libraries that perform essentially the same function, the best, easiest and quickest way to perform that analysis is to stand up small prototypes using each library. Which one to prefer should then become abundantly clear.

Possible cost/benefit considerations for libraries:

  • Maintainability
  • Ease of use
  • Adequate documentation
  • Learning curve
  • Overall performance
  • Buy vs. Build

... etc. Note that many of these considerations can be somewhat subjective.

Whether it's a hobby or a career doesn't matter. You will (and should) use the same process if you decide to continue your explorations into an actual career.

Alternative decision-making strategy: Choose the one you like.

OTHER TIPS

As an addendum to Robert Harvey's excellent answer, here my 2 cents:

Pick the one approach which appears to be the least effort to start with, but make sure you keep the door open for switching to a different approach when it turns out the solution you picked first has too many issues. And if you are suspecting certain problems in certain areas of your usage scenario, make sure you implement those areas first, so you get early feedback, before it is too late to revert your initial decision.

How well this works depends heavily on the case. For example, if you need a simple library for accessing an external device or certain file format, make sure you encapsulate all library access in a layer of your application. However, in case you are unsure about which framework to pick, or which programming language to pick, a thorough cost/benefit analysis is probably all you can do.

Sometimes it is better to just make a decision, even if it is only the 2nd best one, as long as you actually do it.

Licensed under: CC-BY-SA with attribution
scroll top