For this months TSQL-Tuesday Tom Zika asks “Which quality makes code production grade?“

Wow. I feel like I’ve just been tossed a hand grenade and I don’t have a pin. I don’t consider myself a developer by any stretch of the imagination, but there’s a bunch of code out there I have written that is running businesses. Some big businesses. And the idea that there is a grade that any code should pass before it goes into production always makes me a bit nervous, because I’m pretty sure the bar would need to be quite low for everything I’ve ever put out there to pass it.

So let’s step back a moment and talk about this place I live. It’s called reality. And in reality business problems often come to you like this:

Big Manager: The Scurbwazler is about to exceed it’s threshold, we need to offload the thingiwozly workload via the bropfizzle or the whole thing it going to fall over.

Developer: I can get a prototype done that will stop it blowing up, but once the emergency is over we need to go back and make sure it’s performant and secure.

Big Manager: Sure, sure, of course.

(Insert code producing sound effects here).

Developer: Okay it’s done. I’ll look over the security settings after lunc…

Other Big Manager: Hey, what’s going on with the BropFizzle? We’ve releasing our new product today and we need it’s full capacity.

Developer: I guess we could route that via the tertiary system…

And so on it goes.

Now I love the devops movement which makes so many of these problems go away, but I still see changes happen in exactly this way in so many environments, and I totally get the reasons.

So I’m going to try and answer this question from a slightly different angle than what the code should look like and instead talk about how it comes into being.

1. Production Grade Code should be planned.
2. Production Grade Code should be tested before it becomes production code.
3. Production Grade Code should be understood\Documented\In source control.

Let’s deal with them one by one.

Production Grade Code should be planned.

This seems pretty obvious. Before a line of code should be written someone, and probably a group of someones, should define what the code is for and what it’s meant to do. I keep getting told by my developers that the further along the dev process an error gets before being identified the more expensive it is to fix. It stands to reason then that the inception of a requirement is the place you want to focus the most attention to ensure that what you are asking your developers to build is actually the thing you want. Furthermore, time invested in explaining what you’ve just written as a requirement and allowing Q and A time is time that you prevents multiple periods of rework later in the process.

Production Grade Code should be tested before it becomes production code.

You all have a pipeline to run your code through right? Well, if you don’t you don’t need to feel like you are alone. A lot of businesses are still deploying code on a completely adhoc basis and their ‘test’ system bares very little similarity to their production system.

For code to be production grade, it needs to have passed the functionality tests defined in the planning stage, and ideally it will be stress tested against a similar load to production.

In SQL land the classic example is code that is non-SARGable. Functionally it may perform fine against your table with 1000 rows in it, but when it hits production and tries to run against a table with a few billion rows it will bring your server to it’s knees.

Production Grade Code should be understood\Documented\In source control

I’ve been in too many places where only one person understands how systems interact, or how data moves, or what relies on the system you are talking about upgrading\migrating. Inevitably that person will be unavailable. Sometimes they stick around till they retire, sometimes they leave for greener pastures, but they will inevitably leave.

I hate documentation, but I hate lack-of-documentation even more.

I think there’s a period in peoples career lifecycle where they just do heaps of stuff and never document anything and feel productive, but increasingly I don’t want me to be the only guy who understands(and therefore can fix) anything I write. I don’t want to be the bottle neck. I want any competent DBA or developer to be able to look at anything I’ve built and go…ohhh…I see what he’s done here. And then they can fix it instead of me.

And that really is the key to me for what “Production Grade” should be. It’s got to serve a clear purpose, do it’s job and be easily understood and maintainable in the future. To get there we’ve got to get over the idea that code ‘belongs’ to the person who wrote it and think of our code as part of the larger eco-system.