Voice of the DBA

Category: Editorial

  • Building Better Software

    The Do Not Disturb bug would have seemed to be easy to fix, but perhaps there wasn't time before it fixed itself.
    The Do Not Disturb bug would have seemed to be easy to fix, but perhaps there wasn’t time before it fixed itself.

    Why is programming so hard, especially on seemingly simple problems. Here’s a short piece on the Apple iOS6 Do Not Disturb bug that surprised me. The bug is fixed, as of Jan 7, because it was a date issue. According to the article, the programmers that implemented the Do Not Disturb function used the ISO calendaring dates, which do not work as expected this year. The details are in the article, and it reads like an edge case, but it’s not one I’d expect to have slipped by Apple’s QA department.

    These types of programming errors seem to regularly slip by developers. The situation has gotten better since the days of VB6 when it seemed everyone that could complete a week long course was building buggy applications at a frightening rate. While I still think there are plenty of hack developers out there, it seems that with all the publication and information available, there are better programs being built in many organizations.

    However simple bugs can still slip through. The maintenance plan bug in SQL Server 2005 showed Microsoft that there’s no such thing as a simple fix or patch. In this case, even the Apple documentation for developers (Fixed Format section) notes that the ISO date should not take precedence when there is a conflict. Apparently not all of Apple’s developers are following their own documentation.

    Developing software is easy to do, but hard to get right, especially when you are building software that you expect to last a long time and get used in a variety of ways. Experience, practice, learning from your mistakes, and a deep understanding of the business you are working in help developers write better software over time. It’s a reason why you should ensure you work to retain your talented developers. They are much harder to replace than the lines of code they produce. A new developer may produce the same amount of work in a short period, but I’d wager they produce many more bugs as well.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Encryption Not Restriction

    Encryption will be more important in cloud computing
    Encryption will be more important in cloud computing

    I believe in encryption. I have an encryption talk that delivers the very basics of what encryption options exist in SQL Server, and I would think that most data professionals that develop or manage databases should understand encryption and how to enable it. I find lots of people don’t understand, and I’m glad that I can try to teach them a few things about when encryption is and how it works in SQL Server.

    Cloud computing use is growing, and while we don’t have a good definition for what a cloud computing means, more and more organizations are considering looking at moving some of their applications, and data, to the cloud. As we move this data, many DBAs have concerns over the security of the data they are supposed to protect. These are valid concerns, and they should be at the forefront of your mind if you plan on moving anything to any type of service provider.

    One interesting point brought up in this op-ed is that customers ought to have their data encrypted, but the keys used for the encryption should be controlled by the customer, not the service provider. That’s sound business strategy, and it should be the case with all your data, not just data sent to the cloud. If you use a service to rotate and store your tape backups, you ought to have encryption on those tapes, with keys managed by your company. Just as you ought to have the keys inside your company if you use locks on the shipping containers holding the tapes.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Growth of Storage

    Will we see this in a laptop in our lifetime?
    Will we see this in a laptop in our lifetime?

    Over the holidays I had a chat with my son about computers. His laptop died, and he wanted a new one. It isn’t needed for school and my wife and told him he’d need to earn the money for half of a machine and could take the rest from his savings. I’m happy to say that he has been working hard to earn money, out in the 10-20F temps caring for horses, and is getting close to making his first computer purchase.

    In setting his target amount of money to earn, we talked about specifications for various machines, looking online and in local stores. We talked about the various CPU, RAM, and storage values, and what they might mean to him in terms of the performance of a laptop. While we were talking, he asked me some interesting questions about the growth of storage. I thought they were interesting, and decided to ask you this week what you think.

    When will we get 1TB of RAM in a mainstream laptop, and when will we get 100TB of storage?

    Those are large numbers, though I know some DBAs who have one, or even two, terabytes of RAM in large servers. My first thought was that we were a long time from getting those values in consumer machines, but as I look at my phone with 64GB of storage in flash, and this recent announcement of a 2TB SSD, perhaps they aren’t as far away as I might have thought.

    My first professional computer had 4MB of RAM and 200MB-ish hard drive in the early 90s. Today I have a desktop with 24GB of RAM and 2TB of storage. Extrapolating that and I’d expect that I’d have over 1TB of RAM and 20PB of disk in 20 more years.

    What do you think? When will we have laptop machines with the specifications of the largest SQL Server instances today?

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Serious Security

    I almost long for days when security was this simple.
    I almost long for days when security was this simple.

    There’s an interesting piece at Wired on hackers and their impact on security. Despite the constant hacks and cracks of passwords, the regular lectures and pieces written on the subject, many people refuse to use separate passwords on every site, or choose long passphrases, or implement many of the best practices that are published on security. Some of that might be a lack of knowledge, but much of it is likely explained by behavioral economics.

    Most people are never hacked and don’t have issues. Even if they do experience some problem, they can often recover fairly easily. Lots of hacks are just annoying, like using your email account to send SPAM, akin to random vandalism. As a result, many people don’t bother to change their habits. It might also be a tendency that’s hard-wired in our personalities. I’ve educated friends on passwords and given them Password Safe. A few use it religiously, but others keep forgetting, preferring to keep regenerating and changing passwords or re-using them.

    To solve some of these issues and create the behavior that we want, there are suggestions in the article for software designers. One is requiring stronger mechanisms up front, another suggests perhaps changing from alphanumeric pass-phrases to image based ones. One poses the idea of enforcing penalties on users. These might be ways in which we can convince software users to take security more seriously. If it’s true that software is eating the world, then perhaps the designers and developers should do their part to help make sure security is a part of the new world.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.