Voice of the DBA

Category: Editorial

  • Getting Fired

    Have you ever been fired from a job? I hope most of you never have as it’s a somewhat traumatizing experience. I’ve been let go from one (and asked to leave another), and even though I didn’t like the job and wasn’t sorry to be gone, I didn’t like getting fired.

    Awhile back I saw Brent Ozar ask the question on Twitter: “when do you fire a DBA?”. There were a number of answers, and he ended up writing a post that summarized some of the reasons as responses. You can read the post, and the various reasons. I think for most of them, I’d disagree if any incident were the first occurrence of the situation. I know people will make mistakes, and if I don’t forgive accidents, I’ll never have anyone trust me as a manager.

    I also don’t think you let someone go for ignorance. They might never have had to deal with a situation. I don’t think you let them go if they don’t dig deep into systems and find problems. It’s always possible they haven’t gotten to the one item that causes a disaster.

    To me there are two certain places where I’d let someone go. The first is willfully taking part in any illegal activity. I don’t think an officer of an organization can allow that to take place. The second is more subjective. I would have to let you go when you’ve repeatedly shown that you’re not becoming a better employee and making the same mistakes over and over again.

    Failure to learn is not an option.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • The Endless Upgrade Cycle

    Security posts are always interesting to me, and this one on Tesco security is no exception. It’s an analysis from the outside of a number of problems that are blatantly obvious with the way Tesco deals with passwords for their web systems. A great read, one that even your managers might use to better understand why some security processes should be followed. Developers certainly should read this as well, and I’d recommend this as one post to pass around.

    There is one point in the piece that I want to talk about.  In the post, Mr. Hunt mentions that the server software and development platform in use are old, 7 and 9 years old respectively. This section rightly points out that these technologies have been vastly improved, and security has changed. The company should have upgraded.

    Or should they? Obviously if they were really worried about the security of their systems they should have, but how often do they upgrade? When is the upgrade treadmill from software vendors a costly path with little benefit and when is it really necessary? I’d argue that some of the security issues in software should be back ported and fixed. After all, vendors sold these products with the promise they’d work and be supported. Microsoft offers 5 years of mainstream support and 10 years of security support, so at least for the web server, Tesco should be OK.

    I find myself torn on this issue. I certainly understand that software companies need to sell new versions of their products to maintain their businesses, but I also think they bear some responsibility for the security worthiness of their previous versions. Where and how we draw this line, I’m not sure, but I certainly don’t think the answer is as simple as “just upgrade.”

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Inspiring Change

    This editorial was originally published on Nov 5, 2009. It is being re-run as Steve is on vacation.

    I attended the Women in Technology luncheon for the first time at the PASS Summit on Wednesday. My plan was to put in a short appearance and then head to meet some of the Microsoft manageability team to give them feedback on SQL Server. There are times where you realize that something is happening that would be hard to recreate later. I ended up staying at the luncheon.

    There seems to be a decline in engineering, science, and technology degrees and interest in the US in general. The Women in Technology group is concerned with finding ways to interest, excite, and grow the number of women in technology. The panel had a number of women active in technology, sharing their stories and trying to inspire others. It’s a message that I think bears repeating, and gives you the opportunity to break down the stereotypes that exist with women in technology.

    I heard someone say that no young girl wants to be Dilbert. Young men seem to be able to handle that stereotype better than others, and I’m not sure why. Maybe because it’s more socially acceptable for men to be geeks?

    The power of role models is undeniable.  We see that all the time with movie stars, athletes and more. However many of us are inspired by others closer to us. Authors and speakers we meet at the PASS Summit. Technologists that create and sell a company let us dream that we might do the same. Each of us that enjoys our job, and makes a good living, could inspire a young person to consider a career in this field. Just sharing your vision of what’s exciting to you might change their mind.

    I thought the women in technology luncheon was a great event, and I look forward to it next year. I’d encourage the rest of you to give it a try and see if you can inspire a young girl, a minority, or a child you know to consider a career in technology.

    Steve Jones

  • Is Unit Testing Important?

    This editorial was originally published on Nov 10, 2009. It is being re-run as Steve is on vacation.

    I saw a question on the SQLServerCentral ASK site the other day asking about unit testing for T-SQL stored procedures. There weren’t many responses, but they were interesting to me.

    I wondered how many people bothered to test their stored procedures as a unit. It seems that the idea of test driven development, or even of comprehensive testing of SQL code isn’t very mature. If a query runs and appears to return the data we want, do we bother to test for edge or unusual data conditions?

    Or do we even know how to write those kinds of tests?

    Testing your code as it’s being written is a well known way to reduce your technical debt and ensure better code when it’s released. It’s also a way to lower the cost of maintaining your software over its lifetime. However it slows down development as well.

    That’ s not why most people don’t test their code well. The big reason is that it’s B-O-R-I-N-G.

    But does it matter? Is there really an issue? After all most T-SQL queries are built to scale. If the data is correctly assembled into sets with a small set of data, it will work correctly on large sets of data. Maybe not efficiently, but it tends to work. So is unit testing of T-SQL code important?

    My guess is that it is not all that important. At least not as important as performance tuning. If you have extra time to spend on a query, I think most DBAs would prefer to spend it on making the SQL more efficient, not more tested.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed: or now on iTunes!

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.