Voice of the DBA

Category: Editorial

  • Does Speed Compromise Quality?

    One of the parts of DevOps that is often hyped is the speed and frequency of releases. Starting with Flickr and their 10 deployments a day, to Etsy deploying 50 times a day, we’ve seen companies showcasing their deployment frequency. Amazon has reported they deploy code every 11.7 seconds on average. That seems crazy, but with so many applications and lots of developers, not to mention each change being smaller, perhaps it’s not completely crazy. With the forum upgrade here at SQLServerCentral, we had two developers (with occasional other sets of eyes reviewing code changes), and while we were bug fixing, we deployed multiple times per day.

    Is that a good idea? Does a rapid set of changes mean that quality is lower and more bugs are released? It certainly can. In fact, if you’re a development shop that struggles with releases and code quality, producing software faster is not going to help you. In fact, if management pressures you to adopt DevOps, and deliver code faster without culture change, without implementing automated testing, including for your database code, and using automated scripts, tools, or something to deploy software, then you are going to get more bugs out faster. You’ll still get to change direction quicker if you find you’re building the wrong software, but you’ll still end up becoming more inefficient because of bugs (And technical debt).

    There’s a fantastic video (long) about refactoring code in two minutes. A bit of an oxymoron since the presentation is nearly two hours long, but the video is from a real project. However, their approach is that good unit testing allows them to refactor code, to change things, without introducing bugs. That’s a big part of the #DevOps philosophy. I always note in my DevOps presentations that if you can’t implement unit testing, meaning you won’t bother, then you don’t get much benefit from CI, CD, or any DevOps ideas. Tests protect you from yourself (and others).

    In many of the DevOps reports, companies that release faster report fewer bugs and less downtime. Since Amazon has increased their speed, they have 75% fewer outages across the last decade, 90% fewer time down, and many, many fewer deployments causing issues. Turbotax made over 100 production changes during tax season and increased their conversion rates. The State of DevOps reports bear this out (2016 here). Thousands of responses show that speed doesn’t cause more bugs.

    Because they work differently.

    If your management won’t let you change the way you work, if you don’t implement automated unit tests (and other types of tests), if you don’t take advantage of version control, if you don’t ensure every change is scripted, then you won’t work differently, and speed will bring bugs.

    You can do better. Your company can do better. Will they?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Staging Deployments

    This editorial was originally published on Nov 30, 2011. It is being republished as Steve is out of the office.

    Software development can be a complicated dance. Most of us do not work for a software vendor and don’t have the strict requirements for our deployments when we control the client systems. That doesn’t mean it’s easier for us, especially as our environments grow more complex and the availability of our systems becomes more important. Application changes can become disconnected from the database changes, especially when the scope or scale of the change is large, which can present problems.

    Making database changes can be challenging since we must ensure that our data is not lost as objects are altered. We have to ensure that any application functions that depend on a certain schema receive the data they need, without unnecessary errors. The timing of changes becomes more important in the database than in applications in many situations. This Friday I am curious how many of you decide to stage these changes in your environment. If you have dependent changes, I’m wondering if you might alter the database first and change the application in a later deployment.

    How many of you deploy database changes before code changes?

    By “before” I mean you deploy the database changes, possibly making some application changes, but there are other code changes deferred for a separate deployment at a later time. The use of views, defaults, optional parameters and more allow database changes to proceed without accompanying application changes. It may require a bit more work, but the database can potentially be changed during a less busy time, even if development or testing for the all the application changes is not complete.

    The future will require more availability and stability from our systems as they become more essential to our organizations. Learning to update software, and databases, with minimal disruption is a skill that will set you apart in the future.

    Steve Jones

  • Dealing with Supervision

    This editorial was originally released on Feb 4, 2013. It is being republished as Steve is out of the office.

    I’ve been working at home for a decade, first for my own company and now for Red Gate Software. In that time, I’ve learned to manage myself, motivate myself, find work to do, and meet deadlines, all of which I’ve done without having anyone manage me. Over the last five years I’ve worked at Red Gate, I’d like to think that I was one of the easier people to manage since I work well on my own. I’m not sure if my various managers would agree, since I know that I can be particular about how I work and not necessarily work closely with others, but at least I haven’t required much of their time.

    A short while back I was talking with a friend that was under pressure to complete a deployment that was proceeding poorly and their manager stood next to their desk, watching, commenting, and asking how long each process would take. I’ve had to deal with that situation in the past, and it was  maddening to me. It’s hard enough to focus and work on a task when there are problems with the technology. Having someone that can’t contribute but is in a supervisory role nearby usually makes things worse.

    Ultimately I think micro-management says more about the manager than the employee. There are trust issues or control issues, or perhaps pressure from the manager’s boss. It can be hard to deal with micro-management, but if you plan to continue your employment, you need to find some way to deal with it.

    There is no shortage of ideas. You can search for “dealing with micro-management” and you will get a wide variety of advice. I’ve tried different techniques in the past and some have worked, some haven’t. The best way to handle micro-management seems to vary with the situation, but it’s good to have a few things to try.

    Steve Jones

  • Tell Me a Joke

    It’s April 3rd today, and I’m a little sad. We missed April 1 here at SQLServerCentral. The date was on a Saturday, and we don’t send a newsletter on that day, so there wasn’t any opporunity for a prank. Running one today just doesn’t seem right, so we’re foregoing our fun in 2017.

    Over the years, we’ve had some good ones. My favorite was SQL Server on Linux, one of the most popular articles for years, unitl it finally came true. There was my decoding of the DTUs and MySQL supporting T-SQL from last year. Where was also the time we took over PASS. In previous years, I’ve shown you how to throttle a query in mid-execution and  how to get your Service Broken messages in order, and let you enter C# into stored procedures. Do you remember the Easter Egg in SSMS?

    We’ve learned about SQL Server having an open source alternative and the way an index really works. That last one made me proud since I suckered in a few SQL Server experts.

    It’s not just me, Gail Shaw, Paul Randal, Grant Fritchey, and more have participated in April Fools, with some funny ideas, just real enough to be true. I’m always looking for more people to come up with creative April 1 prank, so if you have a good idea, think 2018…

    With Apr 1 being on a holiday, and since I was by myself in the UK (I did run a 5K and work on presentations over the weekend), I thought I’d ask if you had any good links or jokes that appeared on your screen. Anything sucker you in? Anything disappoint you because you wished it were real? Let me know today.

    Steve Jones