This is my first contribution to the T-SQL Tuesday blog party. This month it’s hosted by the impatient DBA. The theme for this month is that we’re still dealing with the same problems.

I hope you don’t all want to throw me out of the party after you finish reading…

Here’s goes. *GULP*

When a graduate sales guy, within a few months of starting his first sales role, (sales!), with no background in IT, (none!), is already regularly, (regularly!), advising experienced data professionals about how to improve their delivery process – there’s a problem. An endemic problem.

And some data professionals still don’t care.

Now granted, this precocious know-it-all sales guy didn’t know the first thing about maintaining or developing databases. If you had asked him to write even a simple SELECT statement he would have struggled to open management studio and connect to the right SQL instance, but he understood a few basic problems and, in principle, how they might be solved. He was able to share this advice with database professionals and those professionals (sometimes) were able to use the advice to solve real problems.

This aggravating sales guy worked for a software tools vendor. That tools vendor sold a database comparison tool. DBAs and developers could use said comparison tool to compare (for example) a development database to a production database, reveal all the differences and script out a deployment script. Over and over this (frankly annoying) sales person would answer the phone to someone who said they had a problem with a deployment, please can they just buy a licence of said comparison tool to help them figure it out.

Rather than politely processing the order this spotty sales kid had the audacity to suggest to the highly qualified and experienced data professional that actually this comparison tool would only fix the symptoms, not the root cause. Every now and then a DBA or developer (or manager, eek!) would become outraged that this glorified call centre operator would have the balls to second guess them and act like he knew more than they did. Sales people, as everyone knows, are just parasites extracting their commission cheques from the already stretched budgets of software businesses. Just imagine how many servers you could buy if your organisation didn’t have to pay sales commission. It doesn’t bare thinking about.

If this smart Alec hadn’t already annoyed the data professional (they were a DBA on this occasion, but not always), what he was about to say would more than likely do the trick. “I’m sorry Mr or Mrs DBA, but buying [said third party comparison product] won’t fix your problem. The real problem is that you don’t know what you need to deploy.”

Boy this kid was in for it now. Claiming that an experienced professional didn’t know what (s)he was deploying? That’s as good as saying they didn’t know what they were doing! Who does this audacious drop-out think he is? Clearly this attitude is why he never got a *real* job.

It got worse.

“I’m sorry Mr or Mrs DBA, but buying [said third party comparison product] won’t fix your problem. The real problem is that you don’t know what you need to deploy. As a consequence you haven’t tested it properly. And by the way, you know you already have potentially dangerous code running in production because you just told me that sometimes you make undocumented ‘hot-fix’ changes there. Basically, you need to re-think your whole process.”

It’s at this point the contemptuous ‘too good for a real job’ youngster even started to raise the eyebrows of his own colleagues. His own manager would stand up from her desk and start to walk over, ready to intervene. She had sales targets to hit and couldn’t afford for this newbie to screw up even the simplest transactions. This should have been money in the bank!

“The real problem is that you don’t have any sort of change control. You aren’t source controlling your SQL. You also need to look at unit testing. Finally, frankly, executing these deployments manually is a bad idea – but we’ll get to that. Let’s start by getting your manager on the phone and discussing all the problems you currently have.”

…

I’m not going to lie – this sales approach didn’t always go well for me.

However, fast forward six years and I’m still having the same conversations, but now I’m doing it as a consultant (and I’m getting paid much more for the trouble :-P). I would still make a terrible DBA, or a terrible developer, (although I can just about type SELECT * FROM nowadays), but after six years solving the same problems again and again and again I’ve earned a certain reputation for being pretty good at a very niche job.

Hey, look, a #DevOps!

Come to the @DLM_Consultants booth to talk about #database lifecycle management #DLM at lunch.#SQLRelay Nottingham. pic.twitter.com/3VfBDyMuXY

— DLM Consultants (@DLM_Consultants) October 6, 2016

The problem for me, is that mine is still seen as a niche role. I find the fact that there is even a market for Database Lifecycle Management (DLM) consultants in the first place pretty sad. It’s 2016 and there are still many SQL folk who don’t version control their databases. The vast majority of the SQL community aren’t doing any automated testing – yet they wonder why they end up with horrible legacy databases that break in unpredictable ways. And for some reason, many SQL folk still love their slow, manual and error-prone deployment processes that by 2016, they must understand, (surely!), are simply embarrassing?

It’s about time we took database change management, testing and deployment seriously. After all, isn’t delivering our businesses’ data requirements in a timely fashion (without breaking stuff) the essence of our job roles? Let’s start doing it properly.

…

Sorry if I just ruined the party. You all seem like nice folk, honestly. And the punch was delicious.

I’ll see myself out.