As a kid, one of the most powerful philosophies I heard was Yoda’s admonition of Luke in the swamps of Dagobah:
Luke: All right, I’ll try.
Yoda: (emphatically) NO. Do, or do not. There is no try.
For some reason, that quote stuck with me all through my late childhood and adolescent years. Either accomplish what you set out to do, or don’t bother. Just "trying" implies that you accept the possibility of failure, and to accept the possibility of failure implies that you aren’t going to give it your full effort.
(As a side note, just in case my folks ever read this blog entry, I didn’t say I always obeyed this philosophy–there were a number of tasks I "tried" rather than "did"–but it stuck with me nonetheless.)
Frequently, when I teach a class, students often call me over to their machines to help debug lab problems, because the results they expect aren’t the results they get. When I ask them what’s happening within the code, they often say, "Well, the system should be…." That’s when I have to stop them with my own rendition of Yoda’s quote:
Ted: (emphatically) NO. The system is, or it is not. There is no should.
See, when programmers start to believe in "should", they’re making an assumption that the system is behaving the way they think, and those very assumptions turn out to be what’s not happening. But because they have faith in the "should", they never go back to verify their assumptions, and as a result, spend hours banging their heads against the wall trying to figure out why it’s not working.
Any time you find yourself saying (either to yourself or your teddy bear–you DO have a teddy bear debugging tool, right?) "The system SHOULD be ….", remember Yoda (and the sharp crack of his gimer stick on your head) and verify your assumptions. Look at the output of the code that SHOULD be sending rpc/literal SOAP messages to the server. Look at the generated code for the server that SHOULD have been built from the WSDL document. Look at the connection status of the socket that SHOULD be open. Look at the server that SHOULD be running, deployed, and available. More often than not, a quick verification of your assumptions will reveal the problem far faster than a rigorous debugging "binary chop" algorithm. And at the end of the day, anything that speeds my debugging is a Good Thing if you ask me. 🙂