Posted in Professional Development, Speaking

New Stars November

I stared this post on my way home from Pass Data Community Summit 2022 and finishing it on Thanksgiving here in the US. There’s something that feels appropriate about this fact. Maybe because it was being inspired after attending PASS Summit 2016 and thinking about what I’m grateful for are intertwined in this one topic.

New Stars of Data is the brainchild of Ben Weissman (t) and William Durkin (t) as a platform for new speakers to get a start in the community. They paired the speaker with a mentor to help them prepare. I was lucky enough to be picked as a mentor and then moderator for this. It’s been amazing to see so many of these speakers become stars in the community so quickly. As a continuation, they have asked other speakers to contribute by writing a blog post about their experience getting started as speakers. (They also have a library of resources for speakers as well so definitely check out the New Stars website!)

Continue reading “New Stars November”
Posted in T-SQL Tuesday

T-SQL Tuesday #156 – Production Grade Code

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.