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
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.