Here’s one post that’s equally valid for bridge and computer programming.
Have you ever accomplished some task and had someone say “Why didn’t you just” do it some other way? Usually their suggestion is assumed to be the obvious or simpler way to do something.
In bridge, maybe you misplayed the hand, or chose a different lead on defense. In software, there’s always some tool or technique that would make the job easier.
The problem with this question is that it’s essentially rhetorical. My answer almost always falls into two camps: either “I didn’t think of that,” or “I didn’t know about that.”
On rare occasions, I actually did know about some alternative method to use, and I rejected it after investigation. That’s quite the exception.
At the bridge table, this takes the form of choosing a line of play that didn’t work on this hand; everyone who chooses the other way is going to get a better result. Most of the time my choice is based on which way has the best odds of being right, but often enough I either don’t know the odds, or have misinterpreted the information I have at the table. Sometimes it’s a toss up, and sometimes I’m acting on a hunch. On rare occasions the opponents have done something clever enough to mislead me!
In software and systems, there’s even a famous acronym that covers this: T.I.M.T.O.W.T.D.I. (from Perl) which means “There is more than one way to do it.” Often enough, it doesn’t matter which way you choose. Sometimes a different approach is simpler, more understandable, more efficient, more something. Often there are so many different ways to do something that you just have to pick one and go with it.
My point is this: Most of the time when you ask this question, you should already know the answer. The question accomplishes little aside from the embarrassment of the recipient.
It’s for this reason that I always dread presenting my work in software, and why code reviews are so painful. It’s nearly impossible to present your own code to a group of programmers without hearing someone say “why didn’t you just …?” Once in a while you will have a reason for rejecting an alternative, but most of the time you just didn’t think of it, or didn’t know about the better alternative.
Here’s what I have to say about that.
When you’re at the bridge table, and you see your partner horribly misplay a hand, give them the benefit of the doubt. Most of the time it’s best to say nothing, but perhaps, “Wow that was really bad luck,” or “Oops, I guess that didn’t work!” Laugh it off and go on to the next one.
In software, things are a little more serious. If you find yourself shaking your head at some technique, design, or code, resist the urge to say “Couldn’t you just refactor the Gizmo object with the Framistat library?”
Instead, try something like, “Hey, I bet if you included the Framistat library we could make the Gizmo object a lot cleaner.” That shows that you already understand that I either didn’t know about the Framistat library or didn’t think of using it. It helps to put a positive spin on the conversation.
In the software business there are so many tools and techniques that it’s often impossible to understand and research all of the alternatives. Having one that works is more valuable than anything else. Discovering true bugs and faults should be the goal. (That, and not having hard tabs in your source code. 
)
Once at the bridge table after making a beatable contract, one of my opponents turned to her partner and said, “Why didn’t you lead a club?”
He responded loudly, “Because your partner is not God!”