Happy T-SQL Tuesday, everyone! I’ve missed the past couple of ones but I’m happy to jump back in. This month, Tom Zika (t | b) asks us to talk about what makes code “production grade”. You can find his full invitation here.
I have to confess that I struggled with this idea. What does “production grade” really mean?
To me, the most obvious part is that code going out into production can pass code review and testing. You don’t want to send out code that has obvious bugs – like having incorrect joins or inaccurate calculations or poor query plans, etc. Code should also go through reviews, not just to make sure the obvious bugs are there but other basic development standards, like naming conventions and proper commenting, have been followed. Hopefully all code has been tested and gone through QA cycles before going to releases. These feel like basic requirements before code goes out. But this also assumes that your company and development team have the means to support this set up. If yours doesn’t, you can (and should) find ways to start implementing aspects of basic reviews and testing to help catch these things before they get sent to production.
This works well to help make sure the small things that we see by themselves are “production ready.” But then we start looking at the bigger picture and cases where things go out in production but they’re not well designed. It’s always “fun” to get into “discussions” with the developers on these issues, point out the problems and potential solutions, have them agree with you, and then spend the next week putting together the scripts for the bad design because they’ve already done the code and it has to go out on Monday. By the way, the promise of “we’ll go back and fix this later” almost never happens. I say “almost” because it may have happened once and I want to make sure those developers get credit for it. But is this code really production ready? Probably not, but it’s going to be anyway. As long as you can make sure it’s as clean as it can be under suboptimal conditions and can pass all of the other requirements of a code review and testing, it’s the best that you can do.
Along those same lines, we have the proof of concept code that works well enough that finds its way into production. Lately, I feel like these are also called “Minimal Viable Products”, or MVPs. I cannot stress enough how much I have grown to dislike using the same MVP initials to mean “minimally viable” or ”most valuable” – it does a disservice to both concepts. These can then be turned into the “alpha” or “beta” releases. We tested it enough that we’re OK letting clients do the real testing for us, with the caveat that they know it’s going to be buggy or not quite work the way they wanted. Hopefully, the functionality and code are designed well enough that the needed changes can be made without requiring a major redesign of the database. But again, these should be following the same basic rules that all code should pass a review and testing.
So the question becomes is “production grade” mean the best possible design along with code that would pass a review and QA? We know that even the code that does meet the standards and even well designed can still cause issues in production and have to be reworked for a variety of reasons. We also know that we may have no choice and send out code that probably shouldn’t go out into production for a variety of reasons but can still pass the basic standards we’ve set up. The basic requirement for me is that everything can pass a code review (no obvious errors in the code, the development team’s coding styles and best practices are used, etc.) and it passes QA testing. As for the other issues, the goal may just have to be creating a strategy to note things that need to be looked at as well as a plan to get the support needed to address them.
In the end, if the little things are “production grade”, it sometimes has to be enough, whether we like it or not.
Thanks for hosting this month, Tom! Looking forward to seeing what everyone else’s “production grade” standards are.
Deb the DBA 