Phil Factor blogged about his quest for SQL Code Smells. He wants to start some discussions about coding standards and best / worst practices.

This is sure to generate a lot of discussion. In fact it already has.

Follow the #sqlcodesmells hashtag and you can follow the discussion. I have tweeted several sql code smells of my own.

There are also some interesting comments on the blog. There is a debate brewing there about the futility of defining standards, art vs. science arguments, etc. One comment even goes so far as "On many a project I have seen coders conform to the arbitrary rule set only to write poor, hard to maintain code."

This often happens, but it does not diminish the importance of such rules. You also can't legislate morality, but we still try.

But such comments avoid the whole point of Code Smells. Code smells are not meant to be dogmatic. They are guidelines meant to point out that there might be something worth investigating.

Code Smells should not be viewed as "arbitrary rules".

Look back over the original Code Smells from Kent Beck and Martin Fowler. They all focus on taking out the antagonism and interjecting a sense of humor.

I have always found that this makes code reviews just a little easier.

I urge everyone to check out Phil's site, contribute your own smells. Approach the whole process with a sense of humor and have fun with it.

Add your comments to Phil's blog or tweet with the #sqlcodesmells hashtag. I would love to hear everyone's thoughts.

What are your most annoying SQL practices? Biggest Pet peeves? Worst practices?

Recently I spoke to my daughter's first grade class about what I do for a living. As a software architect, it is hard to explain what I do for a living. Even among "technical" people, this is difficult to explain.

How do you explain this to First Graders?

I scrambled thinking on my feet trying to come up with an example that I felt First Graders could relate to.

A software system is like the playground at recess. The playground is filled with various programs competing for the slides and swings and their turn in the sandbox.

So far so good!

When everyone plays fair, everyone gets a turn and can enjoy all of the playground equipment and have a good time. One of the many roles for a software architect is to ensure that everyone plays fair and that no one is being a bully.

A bully may damage the playground equipment or refuse to let others take their turn, or keep others from being able to enjoy their turn on the equipment. Someone has to protect everyone from the bullies.

We build in fault tolerance to ensure that a bully doesn't damage the equipment. We design distributed systems to ensure that the playground can scale to accommodate everyone. We also rely on preemptive operating systems and dead lock detections to ensure that individual processes are taking turns.

Turned out it was a pretty good way to talk about what I do.