If something worked before you released and now it doesn’t, it’s pretty peculiar to think something OTHER than your code caused the problem. The correlation is just too strong to deny…unless you never take responsibility, or you have a big enough ego to think everything you write walks on water.

Perhaps “Under the Developer’s control” wasn’t the right phrase to use here. I was more referring to the situation where you have a segregation of responsibilities so that developers only investigate application related issues and an IT Pros will investigate OS or network problems. It is not that a developer is powerless to investigate and fix these issues, but that he or she could decline to do it because they feel it is not their responsibility because underlying problem does not lie on their side of the fence. Although some problems can be resolved faster with this type of segregation due to greater expertise, I think most problems get resolved much more slowly because of the “hot potato” syndrome where each group claims that the problem exist on the other side of the fence. I can accept that people can legitimately disagree about the cause of an issue, but I would at least expect each side would provide evidence for a theory such as event logs, tracing tools, diagnostic software, or Knowledge Base articles before throwing up their arms. My frustration comes into play when theories are tossed around that make it the other person’s problem without any effort to first verify the facts.