Why Me?

In this great post over at codinghorror, Jeff Atwood writes:

You know the feeling. It's happened to all of us at some point: you've pored over the code a dozen times and still can't find a problem with it. But there's some bug or error you can't seem to get rid of. There just has to be something wrong with the machine you're coding on, with the operating system you're running under, with the tools and libraries you're using. There just has to be!
...
Whatever the problem with your software is, take ownership. Start with your code, and investigate further and further outward until you have definitive evidence of where the problem lies.

I think it's not that easy to dismiss any library or framework that you use as source of evil, when hunting down bugs. Software stacks, as the name implies, are assembled of layers of abstraction. Many of them implemented by different teams, even different vendors and in the Java world the underpinning foundation is the JDK, which as we all know is not bug-free after all. If you have to debug code involving 3rd party libraries, you have to deal with other peoples code and that's inherently tough! If you can't find the problem's source, I guess it's only human to start blaming other people's code.

This reminds me of one of my "Database War Stories", where I was about to jump out of the window because of some weird MySQL JDBC Driver behavior. I spent so much time blaming myself for doing something wrong, that I actually debugged the binary going over the wire between MySQL and the JVM. What made it even harder, was the fact that the bug was a Heisenbug and would only show up from time to time. In the end it was a bug in MySQL's JDBC implementation and I'm glad it got fixed pretty soon after I submitted some code to reproduce the problem.

Don't get me wrong, I'm not suggesting you should blame the library or framework vendor next time you encounter one of those bugs, that drives you up the wall. I just think you should do your best to test your code in isolation, so that it touches as few 3rd party code as possible. When that bug shows up during integration testing, you know that the problem most likely lies in the library or framework you are using. Unfortunately, you can never be 100% sure that the way you interact with the 3rd party code is what it's creator intended it to be like. I guess you have to learn that the hard way.