EA Bugs

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” 
   – Brian W. Kernighan

As a long time programmer, I really appreciate that quote.

Brian Kernighan was one the developers of the famous C programming language.  He and his partner, Dennis Ritchie, wrote the original UNIX operating system.  You might say that code is the basis for the entire internet.

One of my first jobs after graduation was in the college’s business incubator.  It was a great opportunity to work with some very talented people. Grad students and professors alike.  (Still not sure how I made that cut 🙂 )

Anyway, we were working on a telephone system for commercial aircraft.  Remember this was 20 years ago, when a cell phone was the size of a shoe box and its battery lasted about 15 minutes!

We were building the hardware and writing the software at the same time, so there were plenty of opportunities for nasty bugs.

One day I was poking around in the lab trying to nail down an issue. I was testing a few different theories when “Professor V” approached and asked what I was doing.

I explained that I had changed the order of some subroutines because I was trying to solve a boot-up problem.

He politely asked what I expected to happen. I really didn’t know what I expected and I told him that.  This was not the right answer.

He sighed and gave me one of those looks. You know, the kind of look that makes you feel like you ran the football in the wrong direction and scored a touchdown for the other team. Not just wrong.  Really wrong.  Like  “How can you possibly not know this?” wrong.

He explained that I had no chance of success using my current approach..

“David, just trying things and seeing what happens won’t cut it.  Way too low of a probability of success.  You need to be able to explain exactly what should happen and why. And when it doesn’t happen – that’s the source of the problem – that’s where you look”.

I learned that debugging is a little like being a trial lawyer: You never ask a question that you don’t know the answer to.

This was natural for Professor V.  He couldn’t even contemplate making changes without having an expected outcome.

I had to learn it that day – and I’ve never forgotten it.

Years later, I’ve applied that lesson, along with many others, to debugging Expert Advisors.  I’ve tried to sum up my method in a recent forum post. You can see it here:

http://www.iexpertadvisor.com/forum/messages.aspx?TopicID=230&MessageID=696#post696 

NOTE: Here’s another tip for debugging:  Explain the problem to someone else.  Anyone. They don’t even need to understand what you are saying.  But the simple act of verbalizing the problem often helps you find the issue.