Database Development Gone Wrong

I recently shared a story about how I was personally responsible for a development project going off the rails (and oh boy, did it go off the rails). It’s a very painful story to share since I was the principal bad guy. However, I learned a lot of lessons from it.

Now, it’s your turn. Redgate Software (yes, my employer), is running a contest between now and March 20, 2019. We want to hear your story about database development gone wrong. It can be a horror story like mine, or just a simple story of the pain involved when developing databases (’cause there’s always a little pain).


What, the chance to $150 or more isn’t inspiring? OK, how about this, here’s Kendra Little’s story about her database development… not disaster really, but certainly, pain.

Here’s another quick one from me:

I was handed a script for a production deployment that had to go out that night. Along with the script I received an instruction, “Run this five times.” I could have just done what was asked, but I wanted to know what was up. So I went to the DBA (yes, a DBA) to find out why I would run the same script five times to get a production deployment done. His response was, “It’ll fail the first four times you run it. So if you run it five times, it’ll work.” Yes, instead of just fixing the order of processing within the script (constraints, stuff like that), he just ran the script over & over until it worked. Unfortunately, I couldn’t delay the deployment, so I ran the script five times. It did work. However, afterwards, I had a LONG chat with the DBA about how we should be doing things.

Actual photograph of me finding out about the script

Enter the Contest!

Please, share your tale of woe, agony and defeat. Kidding. If you have a story about the issues around database development and deployment, you’ve got a good chance of winning. Follow this link now. Remember, you only have until March 20th, 2019. Get it done.

4 thoughts on “Database Development Gone Wrong

  • alent1234

    used to be in a job where we got a bunch of scripts for deployments and the DBA’s had to figure out the correct order to run them in. Those were the good ones. The bad ones were a dozen scripts in one file that would fail if run. We had to select and scroll to run them as individual create or alter procedure

  • Matt51f1

    I recognise that photo of you finding out about the script… it looks a lot like me when finding out that the SOE build for SQL Servers used standard/vanilla settings and no tuning was performed on any instance (while being told to fix the performance problems and not being allowed to adjust those figures).

  • Matt51f1

    I wouldn’t have been able to enter the contest anyway as I wouldn’t know which story to tell…. There are so many to choose from and I don’t have the time to write all of them.

Please let me know what you think about this article or any questions:

This site uses Akismet to reduce spam. Learn how your comment data is processed.