Voice of the DBA

Category: Editorial

  • The Value of Your Personal Data

    Years ago I read Being Digital by Nicholas Negroponte of MIT. In the book, he relates a story about crossing the border from the US into Canada and a Border Patrol agent asking the value of his laptop. He said millions, not because of the hardware, but because of the data. I thought that was interesting, and I somewhat agree. The data I have on my machines, or really now, in cloud services, is more valuable than the hardware. The hardware is barely worth anything to me, including the time it takes to reinstall my applications, because I really treat my laptop as a piece of cattle. I could drop it, render it completely unusable and I’d be back up, running, and productive with new hardware in less than 4 hours.

    Then I saw this article on ransoming data for iCloud users, where the request is for US$75,000. This is for Apple itself and not individuals, but what if it were for each user? What would I pay to avoid losing all the data on my mobile device?

    It certainly wouldn’t be $75,000 despite the fact I think some of the data I have is precious. I love the pictures and video of my family most of all, but if I lost some of them, maybe all of the digital storage, would I just pay a ransom? Probably not. What about all the code in a VCS for my company? Would we pay a ransom for that? Likely we would, though perhaps not. We might think about reconstructing the code, especially if we were a small company.

    Ultimately I think there isn’t a lot of money to be made with individuals’ data. Too many of us older folks remember when we did lose physical objects and they were just gone. The idea of losing things is painful, but not inconceivable. For younger people, it seems that much of the data we produce and consume is transient and isn’t necessarily that valuable to us. My kids love Snapchat for the ability to create and lose memories. I dislike it for the same reason.

    Much of the data we personally have can be backed up, and possibly recreated if it isn’t. Many of our digital records have the characteristic that while we may have a copy, often some business or organization has another copy. Requesting new data is easy, and while it might cost some time and money, it may be preferable to the idea of paying a ransom, and potentially having to continue to pay again in the future with some virus still on our systems.

    I don’t quite know what to think about ransomware and how this might evolve. I suspect that this will always be a problem in some way, just as hardware failures will likely plague us forever. The only solution I have is to create backups regularly that contain versions, and can be restored to separate, clean devices. I’ve gotten away from my own personal offline backups, mostly because of data size, but I do continue to try and keep at least 2 or 3 backups going to different locations and with different services because my data is at least that important.

    Steve Jones

  • 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