I think there are many ways to a suitable, and even great solution. Although the greatest ones might experience, this can be the experience you gather during a career, but also trying things out when you are not sure. All in all I think being able to find a suitable solution is one of the most important aspects of being a professional software developer.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
If possible my team like to 'suck it and see', that is, try a few solutions on the problem for real, especially the difficult bits (eg: hard performance boundaries, working integrations, better UX - measurable things) to the point where the team can identify the crappy bits and how to live with them, the possible gains in our productivity or customer experience, the possible costs and the shape of the learning curve.
Often we end up choosing something less obvious than our original suggestions (pop quiz: choose a static source analysis tool!), as we discover more about our own use case too. A great example of this can be found in the rendering algorithms in Quake - skip down to the end of this chapter and find "an idea that did work" :) bluesnews.com/abrash/chap69.shtml
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No best solution, but most suitable solution.
My question is how can we select a suitable solution?
I think there are many ways to a suitable, and even great solution. Although the greatest ones might experience, this can be the experience you gather during a career, but also trying things out when you are not sure. All in all I think being able to find a suitable solution is one of the most important aspects of being a professional software developer.
If possible my team like to 'suck it and see', that is, try a few solutions on the problem for real, especially the difficult bits (eg: hard performance boundaries, working integrations, better UX - measurable things) to the point where the team can identify the crappy bits and how to live with them, the possible gains in our productivity or customer experience, the possible costs and the shape of the learning curve.
Often we end up choosing something less obvious than our original suggestions (pop quiz: choose a static source analysis tool!), as we discover more about our own use case too. A great example of this can be found in the rendering algorithms in Quake - skip down to the end of this chapter and find "an idea that did work" :) bluesnews.com/abrash/chap69.shtml