After Jim’s post here is Graham and Raj doing a whiteboard desk check of a 250 line query that is running a little wonky.
See my comments to Jim’s first post on this topic.
One of the reasons for desk checking – back in the old’n days – was the cost of punch cards and computer time made it essential to debug as much as possible before standing in line, loading the card deck into the feeder tray, pushing the start button and waiting for the printout with the errors reported in the listing line by line. Then back to the desk for more checking. Yes, my first programming was done on cards in FORTRAN, 360 Assembler and the dreaded COBOL.
My first CMS account on VM was a God send because I could stop carrying decks of punch cards around all day. Can you say GEEK!?
It is very easy to fall into the mode of letting the machine do all the syntax checking and some of the logic debugging just because it’s fast and easy. But is doesn’t absolve us of the owning and checking the logic to ensure it complies with the business rules and technical design.
For the SQL in question (see whiteboard and listing picture in the original note) the wonkiness was that we added a simple test to the SQL that cause the 3-4 minute query to run for many hours. A simple change – the straw that broke the camels back.
What we were trying to do was reduce the sub-query results sets so that the ultimate size of the query would be reduced and therefore improving performance.
Bottom line, Moore’s Law and advancements in computing technology let’s us get away with a lot of stuff – like who cares these days that XML is all interpreted and not compiled? — So a powerful PC can get all the syntax errors out and won’t complain if we write queries with crappy performance most of the time…but not all the time… and the picture above was one of those times when the query was complex enough that some desk checking and peer review would have come in real handy…I’m still working on making this one better.
I think that is a great example of teamwork and egoless programming. Let’s just solve the problem. Great to have a new set of eyes. Posting it up on the white wall is a great idea.
OK, in this case you are correct, this is a piece of code that has been in production. It had been evolved and tested to a point and 2 days before it went into production it was changed – skipping our usual rigor to try and meet a changed need at the last minute.
The point here though was that you could do this before.
As well, leveraging the white board, an ability to create a larger conversation amongst a number of people was really interesting to observe. By the time I left 2 other members of the team had walked up and were adding some context and support.
That is a great picture. However the activity looks like it is after the fact when you are trying to find a bug.
The most effective desk checking occurs before you try to run the code. The temptation is to try the code before you desk check it. My experience is if you check it before you try to run it means you have not preconceived notions about what works and what does not. I wonder does anybody do that anymore.
A simple metaphor might be helpful. When you ask a computer to check something you have written, it can check spelling and grammar, but cannot check if the content makes sense and is clear to the reader. That requires careful reading of the prose before anybody else sees it. Sometimes putting the document together takes such effort that you have no more patience to check the sense and clarity.
In desk checking, does anybody ever check a program that they think works, to check if there are any holes in the logic?
I also think that you have a different attitude before you try the program. However maybe the logic in these high level languages is so simple, there cannot be holes in the logic. However if something is going wonky then there is an error in the syntax or logic somewhere; however tempting it is to blame something else.
I think this is origin of Murphy’s Law.