Voice of the DBA

Category: Editorial

  • Where’s the Unit Testing?

    I’ve been a proponent of Unit Testing, especially for databases. I’ve given presentations on the topic and advocate the use of techniques to verify your code works, especially over time when the complexity grows, new developers change code, and potentially introduce regressions. I’m not the only one as I saw a question recently from Ben Taylor asking where has unit testing gone?

    I was disappointed that few people have responded to the piece, and I think this is the same response that unit testing in front end application software received a decade or two ago. Few people saw value in testing, preferring to assume developers will code well. Over time, and with some investment, quite a few people have seen the value of unit testing, though I’m not sure it’s the majority yet. In building database software, we’re still woefully behind, preferring to use ad hoc tests that are subject to human frailty (forgetfulness, making mistakes in running tests or not examining results closely).

    I do know a few people that are customers of Redgate and use unit testing extensively in their database code. They definitely spend a lot of effort building unit tests, often having more test code than feature code, but they also have very low rates of complaints and bugs from users. I hope that more people having success will publish details on their unit testing successes and failures, and I’d welcome more pieces at SQLServerCentral on either side of the issue.

    For many people writing in-house applications, especially those installed in one location, perhaps a few bugs aren’t a problem. Maybe the impact is low enough that training developers to write tests and making the investment isn’t valuable enough.  However, for those that have disparate external clients, or maybe install software in many locations, I bet that moving to a more thorough set of repeatable, reliable, non-trivial tests will improve your software quality.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Relentless Cloud

    The march to the cloud is inevitable. No, I don’t think all your services will be run from a cloud service, but I do think that some of them will be. Maybe 10% for your company, maybe 90%, but likely somewhere in between. In the efforts to reduce costs, and maybe more likely, the idea of shifting costs to expenses, I would bet that most organiztions will take serious looks at the cloud in the next decade for a significant portion of all new services. They might not move most applications, but they’ll think about it.

    I saw a note recently on Geekwire that Azure is estimated to exceed  Amazon Web Services (AWS) by 2019. Most of us might not care about the race between these two tech giants to build large cloud infrastructures, but their capital expenditure is based on the idea that your organizations will want to use some of those services. They have good reasons to think this with surveys and conversations with many of their customers.

    In the absence of changing tax policy in many nations, it also makes more sense to make move costs to expense, rather than capital expenditures. And that’s the way things are going, at least according to what CIOs are saying. More and more applications and services will be moving to the cloud in the next few years. Up to 30% from the current 14% of applications today. As I’ve seen more and more entreprises, public and private, moving mail and web services to outsourcing providers like O365, I also think we’ll see other applications moving.

    I don’t think every application is suited to an outsourced area, but I do think there’s a case to be made for many of them, including databases. For those with privacy or security issues, cloud providers are working to mitigate the issues. Amazon has built separate data centers for government services, and I believe Azure is (or has) done so as well. The challenges that exist can be solved, and many of the risks or concerns will be mitigated, though you’ll still need to evaluate your situation on a case by case basis, which will change over time.

    My recommendation: learn about the cloud.  Really learn, don’t just assume you know. It will be good for your career.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Scary Deployments

    I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn’t been fixed. The reason? This quote:

    “Very few people understand how the entire system works that are still in the building … The thought of deploying [changes] brought people to tears.”

    That can’t happen. Ever. We can’t be afraid to touch systems. When this happens we get paralyzed, and we don’t do good work. Or we’re not a good fit for a project. Or perhaps, we’ve got a bad attitude.

    I’ve worked in a few companies where developers were afraid to touch a system. It’s amazing how quickly this attitude becomes contagious, even scaring management from considering change. In today’s world, where it seems to need to change and respond to a changing world, that seems like a recipe for decline, not growth.

    One of the founders at Redgate mentioned that if something is hard, we should do it more. If touching software is hard, document and test more. If deployment are scary, then you should work to reduce the fear and problems, using the power of computing and scripting to mitigate risks and smooth the process out. That’s a large part of what DevOps is about. Reducing the risk and issue of moving software from the development to production environments.

    Don’t let yourself be scared by software or deploying changes to a system. Have confidence and make things better.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Security is Getting Serious

    OK, if we can’t trust computer chips, what do we do? It almost feels like the security war to protect information, or at least keep it private, might be lost before our very eyes in the next decade.

    There’s a story about a back door being hidden inside a chip. That’s nefarious, and entirely plausable. After all, how many people, forget about the millions that aren’t technical, how many people in the world can analyze chip designs for back doors? How many people would have to be corrupted, bribed, threatened, etc to make this happen? It’s probably very few.

    We have enough issues with back doors or flaws in software. We can’t even patch, upgrade, or change that quickly. Imagine if computer chips in PCs, routers, wifi cards, really any widely used device had a back door implanted? We would have fundamental security flaws for quite some time.

    This sounds like a movie plot and I really hope that’s the level of reality here. However, as more companies look to spec their own hardware, especially large cloud vendors, this is disconcerting. After all, inside a company there can’t be extensive reviews of designs for security flaws. Many companies might outsource the manufacturing of their chips to another company. In that case, could employees of the manufacturer look to embed back doors in chips? I’d hope designs are presented, manudactured, and then discarded quick enough to prevent anyone from engineering a back door into the hardware, but I’m not sure how difficult this is, or how much change would be needed to a design.

    I suppose there isn’t much any of us can do if this possibility is feasible, but we certainly can keep abreast of security issues and perhaps ensure we use a variety of hardware so that any particular issue doesn’t affect our entire infrastructure.

    Steve Jones

    The Voice of the DBA Podcast

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