Friday 8 May 2009

The Philosophy of Mistakes: Work In Progress Has No Mistakes

I have been thinking about mistakes recently. How I make them, why I make them and why I seem to make so many of them on spreadsheets, presentations and code. That would be me and you and everyone you know as well.

The guru of errors is Professor Raymond Panko at the University of Hawaii. His site, which is well worth a detailed read, contains many reassuring figures, amongst which is that even experts make mistakes in 22% of their SQL queries (on a text editor rather than a Access-style designer, I assume).

This sounds right. I start with a business problem and “write” the query. At this point I'm really thinking about what fields and calculations I want and what conditions I need in the WHERE and HAVING clauses. I am not thinking about SQL syntax and so what I've written is full of SQL solecisms, but I can't see them because I'm not looking for them, I'm looking at field names and dates and conditions and other content. I'm not looking for commas, un-paired brackets and other such things. Plus I forgot that “salesvalue” has an underscore “sales_value”. So I hit run and the complier hits me with all the solecisms, and the next time I get the 'can't group on an aggregate' and related errors. Damn. Left out the City name. So I add that and run the query – ooops, forgot to change the “group by” clause to include the new field.

What I'm really doing here is clarifying and then solving a business problem by writing an SQL query. As a result there are a lot of false starts, as I correct the syntax, then correct the content of the WHERE and HAVING clauses, then change the calculations for some of the aggregate fields I want, then realise I need more or different fields... and so on.

Of course, I was supposed to clarify the problem and then specify the query first, before cutting the code – but that just shifts the false starts to a scrap of paper. Plus I can guarantee that even when you do write the thought-through, specified query, there will still be a comma missing and you will realise you needed an extra field.

Now, while I'm in this loop, concentrating neither on the SQL syntax, nor on the correct spelling of fields names, nor on the content of the query, but flicking from one to the other, I'm in a work-in-progress. While it's a work in progress, there will always be stuff that is not done yet, mis-spelled, not formatted nice and badly coded. These aren't “mistakes” because you're not finished yet. Mistakes only exist in the release version though there are people who will look at your work-in-progress and loudly announce all the things you haven't gotten round to yet as if you forgot them. (Those people are destined for a long time in the grey wastes of Purgatory.)

There may be no mistakes, but there can be a lot of frustration as I wonder why it's all taking so long for my poor, tired brain to cope with it. Which will be what the next post on this subject will be about.

No comments:

Post a Comment