Hypocrisy has got to be one of the most infuriating traits of human beings.

Definition:

"A pretense of having a virtuous character, moral or religious beliefs or principles, etc., that one does not really possess." http://dictionary.reference.com/browse/hypocrisy

In other words: "Do as I say, not as I do."

Classic late 20^th century example of hypocrisy: While attacking President Clinton for his sexual dalliances in the Oval Office, Newt Gingrich was committing adultery himself. Oh, and he served divorce papers to his wife while she was in hospital recovering from cancer surgery. A real family values kind of guy!

And now I would like to volunteer myself as another living example of hypocrisy.

I spend a lot of my time in public talking about best practices. In other words, I stand up in front of other developers and act "holier than thou," offering advice and admonitions along the lines of "Do this, don't do that, and certainly never do that."

Occasionally, I am honest enough to point out that I do not always follow all my best practices. And students in my classes not infrequently are delighted to point out violations of best practices in the code I am presenting to the class.

And I do think that lots of my code is at least reasonably well-written.

Sometimes, though, the way that I ignore my own recommendations is so over-the-top and painful that my hypocrisy is brought to the fore – and I feel compelled to make a confession.

I was in Europe last week, presenting Quest® Code Tester to developers, DBAs and managers in Paris, Brussels and Maidenhead (UK). When not in the "public eye," I kept myself very busy debugging some of Quest Code Tester's backend code (on which I am the lead developer) – as well as working on the second edition of Oracle PL/SQL Best Practices for O'Reilly Media.

Now, as I am sure you all know, debugging code can be a frustrating, time-consuming adventure (even if you take advantage of Toad's great source code debugger). And this brings me to the source of my hypocrisy.

One of the recommendations I make to developers is to follow The Thirty Minute Rule:

If you cannot figure out the source of your problem
in thirty minutes or less, then stop and ask for help.

Why do I say this? Because if you cannot figure out the problem relatively quickly, you are unlikely to find the solution in another hour, or two hours, or three hours. You are too deeply inside the problem to get an objective viewpoint and question your assumptions.

And the more you struggle within that problem space, the less rationally you approach the problem, the more time you waste, and the more you simply "try" things to see if they might "work."

Does this sound familiar? Ok, so that is the advice I give and on Wednesday night, I sat in my room at the Holiday Inn in Maidenhead from 7 PM to midnight putting dents in the desk with my head.

My problem: in Quest Code Tester, you can define dynamic test cases based on pre-defined groups of values or values retrieved via a query from a test data table. That's not the problem. That is a great feature. Unfortunately, the results of these tests (generated at test time) were not rolling up properly when the program being tested raised an unhandled exception. In other words, they were showing success when they should show failure, and vice-versa.

No doubt about it, the code that performed the roll-up was complicated stuff, made more challenging by my reliance on a three-level, string-indexed nested collection structure. Those things are not at all easy to debug.

It also turned into one of those scenarios in which, as you fix one bug, you realize that code you thought was working by design was actually working by accident. That is, bugs that were previously being masked were now exposed by other fixes. Wow, software can be incredibly complex!

So I would fix one bug and then find others, fix those and then...it was 10 PM and I started to encounter behavior (duplicate result rows with different outcomes) that I simply could not explain. So I struggled for two more hours, eyes tired, back sore, thirsty and increasingly angry, until I gave up and went to bed.

Woke up six hours later, with an idea hopping around excitedly in my head: I could suddenly and very clearly see how I was getting duplicates, where it must be occurring in my code. I hurried to my laptop (easy: it was four feet away) and ten minutes later confirmed my analysis. Fixed that bug, found another, analyzed it, fixed it. AFter thirty minutes, my code was working for all test scenarios.

I sat back in my chair, a little bit stunned – excited, sure, at having found the solution. But also thoroughly disgusted at myself for wasting so much time the night before. How could I have done that? I knew better. But more than that, I regularly preached better. What a hypocrite!

So, this is what I learned (or was so painfully reminded of) from my terrible, horrible, no good, very bad* evening with the qu_result_xp package (and other similar experience):

·          The Thirty Minute Rule really does work and you should apply it rigorously. Do not spend hours banging your head against the wall of your code. Ask for help. if your manager has not set up a process or fostered a culture that says it's OK to admit ignorance, you have to do it yourself. This is especially important if you are (or are seen as) a senior developer on your team. Go to a junior team member and ask for help. They will be flattered, their self-esteem increased. And they will help you solve your problem.

·          If you stuck and cannot turn to another programmer for help, then ask a non-programmer for a sympathetic ear. My friend and Quest Code Tester co-developer, Leonid, told me that he used to ask his grandmother, not known for her programming skills, to listen to him talk about his work. Externalizing your thoughts, even to someone ignorant of the content, helps you organize and clarify your thoughts.

·          If you are stuck and alone and cannot turn to another programmer or other human being, then STOP! Take a break. Get away from your work. Best alternative: get some exercise. Move your body. Go out for a walk or a run. Jump up and down, stretch, do sit-ups. Let your brain relax, make its connections, and suddenly as if by a miracle that incredible brain of yours will come up with a solution! And when you come back from your break, try talking out loud to yourself, describing the problem. Or take out a piece of paper and write it down. The key thing is to get it outside of your head. You will then find it easier to look visualize the problem and the solution,

·          You know that you are past the point of productive work when you find yourself thinking in less than rational ways. I can still remember back in 1992 when I was building a debugger for SQL*Forms 3 on Oracle's brand-new PC implementation (first software to use memory above the 640K limit!). I started to get runtime errors, and I discovered that if I added a tab character to the code, the location of the error would change. I sat there for hours trying to find the source of the problem (typing in extra spaces, returns, etc.), when OBVIOUSLY it was a bug down deep in Oracle. PL/SQL does not care about white space. When you find yourself saying "What my program is doing is impossible and makes no sense." you really should stop and take a break.

And there you have it: my confession. To be very honest with you, I don't think I am all that great a programmer. I have a quick mind and am good at communicating ideas. But I need lots more discipline and patience as I write my code. And I need to apply my (and others') best practices more regularly and thoroughly.

So remember: do as I say, not as I do!

* I draw that phrase from my days of reading books to my son, Eli. The book I reference is Alexander and the Terrible, Horrible, No Good, Very Bad Day. If you have small children and are not familiar with this book, I recommend you get it!