It’s a busy time for me, but it’s also T-SQL Tuesday blog party day. I’m rushing a bit as I forgot about this (thanks for the reminder, Deb) and had to help on the ranch this morning.
In any case, a moment of Zen.
Now, for the T-SQL Tuesday post to answer Tom’s invitation.
The Quality Bar
Lots of code gets through to production. I suspect many of us agree that not all of this is production quality. Often we find issues with code that doesn’t perform well or even meet the specs of what we required.
I haven’t had to put much code in production in the last decade, but I do remember doing so, and I remember supporting code. To me, the code quality that defines production is this:
Does it make my phone ring?
If the answer is no, it’s production quality. If it does, then it’s not. That’s how I’ve worked on things in the past, and it’s served me well.
You might argue, Steve, that doesn’t help. How do I know what code will meet that metric? There’s no easy answer there. You need to know the system, the requirements, the clients, and the workload. There is a lot that goes into deciding how to build code and what commands, structures, architecture, etc. is suitable.
A few examples. In SQL Server, we avoid cursors because they are not efficient. However, if I have very rare processes, or sometimes on-offs, a cursor might work fine. If it doesn’t overload the server, runs fast enough, and gets the job done, why not?
Another example is using CTEs to pre-aggregate some totals so that I can write a simpler query for a report with related data that isn’t aggregated. This might not be very efficient, and might create a lot of logical reads. However, if the report isn’t a problem with the server workload, is it production quality? I think it is.
The caveat to this is you also need to know data growth. What is production quality today might not be in a year. Potentially we need to refactor code later. That’s fine for me if the situation changes, but it’s not fine if I can forecast this being a problem and I have a better technique, perhaps with some WINDOW functions and less CTEs. I don’t want to defer work unless I don’t have a choice. If I can write better code today, I should.
This also means I ought to be learning more about how to produce better code from others on a regular basis.
Voice of the DBA 
From the article…
“Does it make my phone ring?
If the answer is no, it’s production quality. If it does, then it’s not. ”
That didn’t work when the “new” SSC came online. Several of us put many hours into testing and listing faults that needed to be fixed. None of those faults were fixed prior to the release. After many calls that your “customers” should have not had to make, things finally got kind of fixed.
And then there are repetitive problems that shouldn’t be repeating. For example, the email notifications are broken (again) and I’ve sent a couple of emails to the WebMaster. I’ve gotten crickets in return. They’ve actually been broken since Oct 26th and I didn’t send a notification earlier on the hopes that someone that changed some code somewhere would have noticed the mistake they’ve made.
To wit, if the phone doesn’t ring, it may be because you no longer have any customers. 😉
LikeLike