How long should you obsess for the perfect solution before moving on?

gistfile1.txt

Its minor part of a feature, but I’ve been obsessing about the best way to solve this for a while. 

To the point where I’m starting to wonder if I’ll ever get this done. It’s not a big problem, not life or death. Might be the tiniest little performance effect (I’m debating with myself the best way to handle references and communication between two viewmodels, and whether or not to use a strong or a weak reference, eager or lazy loading of objects, and whether or not to cache), and of course architectural effect. 

I certainly don’t want to mess things up and add a tiny clog, but honestly I’m probably more worried about checking in code that isn’t fantastic as I want to show that I can do a good job. I’ve coded up 5 ways to solve achieve the desired result, and I’ve had two code reviews and three discussions with in total five developers. 
At what point do I move on? And how do you know when to move and just pick something? 

I feel like I’m analyzing this thing to death. 

Would love some advice on this :)

XKCD post - http://xkcd.com/1205/

Whenever I find myself in this situation, of finding the perfect balance between performance and architectural beauty at the cost of time wasted. I remind myself that software is malleable and as long as I stick to good principals for architecture, this piece of software can be changed later on. And most times later on the code becomes simpler and more clear, because the path is better defined.

It seems you're obsessing over perceived performance characteristics and the possible impacts a solution to those perceptions will have on the architecture.

The golden rule, in my view, regarding performance is to never take action without data. So load test the solutions you have readily available to get that data - now you can make informed choices on what to do next regarding architectural changes etc. The first implementation of any algorithm or indeed product will never be perfect, make a best effort, get feedback, refine it and repeat as necessary. If the performance hit is negligible or doesn't matter (based on the performance criteria of the architecture), having considered the reviewers comments, you choose the most readable/understandable solution - in your view.

Don't worry about code that isn't fantastic - you will never please everyone with your code, but continuous feedback is essential - that feedback comes from peers, customers and the software/hardware itself. You should seek it out as often as possible and don't be concerned about perceptions of doing a good job, that will have nothing to do with a couple of commits of code but your contributions over time.