Catching Minor Issues

This seems like something out of a thriller that Hollywood made for a spy. Someone switches two cables in a rocket and then it crashes. However, it’s what happened recently, not from a spy, but an employee somewhere connected two cables to the wrong connectors, resulting in reverse commands being sent to the rocket.

That sounds crazy. Who would plug cables in backwards, and how is this not caught? Surely we wouldn’t run into this in software would we? With all the unit testing? Well, we did once have an English->metric error.

Actually, I’ve seen this in software. I’ve seen someone pass parameters in backwards to a method or stored procedure. I think I’ve done this before as well. While I hate typing out named parameters, I do appreciate SQL Prompt for ensuring I connect the right value to the right parameter by spelling them out.

Do you type out parameter names, as in EXEC myProc @Param1 = @value1, @param2 = @value2? It’s a good habit to get into to prevent simple mistakes. In fact, this is where some simple, quick tests can catch errors. Not only will this catch some weird changes, this can ensure that your procedures are backwards compatible. That’s often a concern in refactoring, where someone might not think a parameter is being used, or wants to replace it and then breaks other code.

Testing is something that has improved in software dramatically over the years, though not as much in databases as I’d like. I urge you to use more procedures, but also add more tests and ensure that you don’t make simple errors that should be caught.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

1 Response to Catching Minor Issues

  1. pianorayk says:

    This is why I am passionate about what I do. Good and well-designed documentation prevents errors like these.


Comments are closed.