Many times I have run into this type of problem, usually I will move on to another project for a day or so and then come back to the problem. 99.99% of the time I will have three or four ways to attack the problem the next day! I agree that talking the problem out with others also gives you some fresh ideas on how to solve a problem.

As for handing the solving of a bug over to someone else, well there is no one else, at my company, to hand it over to, so it is my problem and I have to solve it.

I work on Medical devices, so there is a rigorous set of requirements for software design, software implementation, software testing and software verification and validation.
Most of the documentation required is basically good engineering practices focusing on the design of the software.
These requirements came about because the FDA did a study on medical device software failures and found that 95% of the failures were due to poor software design. The classic example was an electronic wheelchair that went crazy because someone used a cellphone in close proximity to it, or another example was a medical device used for treating cancer tumors that exceeded the radiation dosage and killed the patient because of a software malfunction.

Jacob