It’s that time of the month again! It’s T-SQL Tuesday and this month Tom Zika (blog|twitter) is hosting. Tom would like us to talk about What makes code production grade?
One of the things that I love most about being a DBA is how often the answer is it depends. (Pro-tip: Never say it depends without talking about why it depends.) Production grade could mean how robust the code is (how often will it fail and what happens if it does), how well it performs (it’s all well and good if the code blazes when you’re dealing with 10 rows but how about 10 million?), and how easy is it to maintain? (Yes, your code may still be in use 10, 15, even 20 years later. Someone’s going to have to deal with it.)
I’ll be honest, all of that is pretty variable. It depends. There are lots of different types of code used in production.
For example, if your code is something you’ll be using yourself, you may not care about how robust it is. I mean you need to make sure it won’t do any harm if it fails, either through restartable steps, rolling back transactions, etc. But if it fails you’re right there to fix whatever went wrong and move on. You can almost think of it as a set of notes on how to do a process. Maintenance is also less of an issue because no one else is likely to be looking at it but you. You still probably want some documentation in case it’s been a while since you used the code and you’ve forgotten how that tricky bit works. And performance? Well, how patient are you? I’m not overly patient so performance is pretty important for code I’m running manually.
Next, you have code that you’ve written, that someone else is going to be running manually. Say something you are posting on the internet. This code needs to be pretty robust. You don’t know how skilled the person running it is and they might run into problems. Performance doesn’t really change here. It’s still pretty important. Someone is waiting on it to finish and who knows how patient they are? And last but not least is maintenance/documentation. This time it’s super important. Someone else needs to be able to pick this code up, with no help from you, run it without an issue, make changes that could range from minor to major, and deal with any problems that could come up. Document the heck out of it.
Then there is code that’s going into an application. Now we need to make sure this code not only doesn’t break but if for some reason it does it needs to handle it gracefully. There isn’t a developer there of any type to fix things so it has to handle it itself or at least report the error gracefully with useful information. Performance again is important but no more than in the last two cases. Maintainability/documentation is somewhere between the first two cases. You may not be the one making changes or needing to understand the code, but, at least in theory, any work on the code will be done in a test environment with plenty of time to work out what’s going on.
Last but not least (at least for this post) you have automated or batch code. This code has no human involved so how it deals with failures is going to depend on the requirements. Sometimes the code can fail and move on, sometimes it will need to retry, and of course, sometimes it needs to alert someone to a problem. Performance is actually less of an issue here. I don’t want to sit and wait even five minutes for a piece of code to finish, but code running in the background? I may not care if it takes hours or even days. Maintainability/documentation is going to be exactly the same as application code. Changes and testing may not be done by you, but they should be made when there is time to figure things out. You still want to be kind to the next person but they won’t be doing anything on the fly (hopefully).
So next time you are wondering is my code production ready? First stop and think about what the code will be used for and how that affects production grade.