Voice of the DBA

Category: Editorial

  • The Blame Game

    Make no mistake, this is going to be something that happens again. The former CEO of Equifax blames their massive data breach on a bad scanner and a person. I’m not talking about a data breach, of course those are going to happen, and when they do, assume that every piece of data in the system is compromised. I know some digital forensic scientists are really talented, but is a company that didn’t necessarily pay attention to security in the first place going to ensure the analysis is done right? Not likely. Assume every record is compromised.

    In this case, the former CEO calls out a person that made a mistake, and then says technology failed. I don’t think that’s true, and I’d agree with Patrick McKenzie, who has a good thread on Twitter. A bad engineering decision, or even a process, is the result of multiple people making mistakes. Certainly there are people that must back up the Apache Struts patch person when they’re on vacation. Or there should be. If there isn’t, then that’s a management failure at multiple levels.

    The thing that concerns me is that we, as tech workers, are going to be blamed going forward. The individual isn’t named here, but I bet at some point they will be. And some, or many, tech workers will get sacrificed for a company that wants to show contrition and action for security mistakes. It’s common for someone to take the blame, but I haven’t seen a specific person be identified (or their inaction be called out) in the past. I’m sure some tech people were probably fired after previous incidents at large companies, but not publicly.

    While the person wasn’t named, there was a report that this individual was no longer employed. Fired? Quit? Who knows. Certainly it’s likely that once this breach became public, anyone who might have been responsible for watching CERT lists, applying patches, or anything to do with Apache Struts might be blamed. In fact, I don’t know I’d want to continue working at a company that might publicly blame my role for a massive breach. My career might be dead with that management, so I might as well move on. Much easier for everyone to blame me than accept responsibility.

    This is the first time I’ve seen an IT employee blamed. BA said an IT systems failure with their major issues. Yahoo and Target were hacked, but no one in IT was blamed. Sony didn’t blame their IT staff after their emails and films were released. Yet Equifax did. I hope this isn’t a sign of things to come.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Time is Precious

    I’ll hear people constantly say they don’t have time to work on their career. They can’t attend a UG meeting to network. They can’t spare a minute to go through a Stairway Series. They have family commitments, kids, hobbies, volunteer activities, spiritual needs, and more. That’s not even counting all the work they need to get done as a part of their job. When can they spend time on R or Machine Learning or CosmosDB or anything else?

    I get it. My life is chaotic as well, with deadlines and a pile of work that never goes away. I sometimes dread travel and vacation because that means my work piles up on either side of those events. This is on top of commitments to keep up on chores at home (I have cooking and laundry), fix things at the ranch, spend time with kids, get date nights with my wife, and still get to the gym. Most weeks feel like a crazy treadmill for me.

    In my life and career, I’ve learned a few things. One of which is that I need to prioritize what’s important to me. That often helps me decide when to do X instead of Y. I regularly make choices between opportunities, but I also try to evaluate the relative importance of events. I rarely miss family events or kid activities, but sometimes I do. I know that there are times that I feel my work is more important in the moment. However, I try to balance those out to be sure I remember that family is more important overall.

    I’ve also learned that I can find time for things that are important. I have to adjust priorities and scheduling. It is important to not just overload myself with more work, which is easy to do. I find that if I try to get more done in a week, I can’t do that for long. Like a big project at work, I’ll burn out without balance. Instead, I’ve learned to let something go a bit, or cut back on some part of my life to make a little time.

    Everyone can spare some time. Especially those of us in the technology industry. We need to learn and grow, even if it’s just for ourselves. We need to keep our brain’s active, and on a regular basis, we should try something new. Other professions can do this, and we should as well.

    I know you can’t dedicate a half a day a week to a class, but maybe you can spend 30 minutes or so working through a book. I know you can’t make the user group every month, but you can make one or two meetings a year if that’s something you enjoy. You can’t go through all our Stairways, or maybe not even all of the Indexing levels in that series, but you can start learning a bit more with one. Perhaps you can’t make SQL Saturday this year in your area, but is it worth a bit of your day to watch a presentation from the SQL Bits archives?

    I bet it’s possible, and I bet you can find a little time every month or two to grow a bit as a technology craftsman. Make sure you take care of yourself, and actively work on your career, in balance with the rest of your life.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Citizen Scientists

    The last few years have seen quite a bit of demand for people that can analyze data. Certainly the Microsoft platform has embraced more ways to import and visualize data with tools like Power BI, more intelligent analysis with SQL Server Machine Learning and Azure Machine Learning. I think this is because there’s been quite a demand for data scientists, and with all the media attention, plenty of IT executives are searching for these people.

    It’s a good time to change to that type of career, if it’s what you want. You certainly should investigate what’s involved if you have any interest. Buck Woody has a Data Science series that can help you. Microsoft has a Professional Program in Data Science, and there are not shortage of R and Python resources that can help you experiment with data analysis in a new way. SQL queries work well, but you might find that having other tools in your toolbox is helpful.

    As much as there is a demand for professionals, Microsoft, Amazon, Google, and others are trying to find ways to reduce the cumbersome nature of the tools so that anyone that understands the science part can do the work. Will this mean the average business analyst be able to leverage tools and platforms to perform complex data analysis? Maybe, but I don’t believe these citizen scientists will remove the need for dedicated professionals. There’s an argument in this piece that they might, so you’ll have to decide what you think.

    The danger is that it becomes so easy to perform some analysis and create a visualization that we will likely have lots of people building reports and drawing conclusions without really understanding how they’ve aggregated or filtered data, perhaps without even understanding the implication of making these changes. I could see all sorts of poor decisions being made because a manager thinks anyone can use a tool to extract information from data, so they let just anyone do so.

    Maybe this is where the data scientist steps in. Help users to refine their analysis, understand the problems when data is put together or taken apart with these tools. Certainly they should ensure that users have good, clean data sets. The last thing we want is another IT bottleneck, but perhaps using highly technical people to review other analysis and ensure no fundamental mistakes are being made by the analysts is a good use of IT skills.

    This is another place where we need to ensure that different groups inside of a company can work together to be more effective for the organization. That’s the DevOps mentality. We get things done, regardless of who does the work or whose responsibility it is on paper.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Don’t Use Code Coverage

    I got asked in a seminar recently how to perform code coverage for T-SQL. There aren’t a lot of options, but there is a project from Ed Elliot called SQLCover that looks to examine how much of your code gets called from a test. There may be other methods, but my question back was why does code coverage matter? There were a few reasons given by various people, but ultimately the original questioner said that their boss wanted a report.

    That’s fine, and it’s a valid reason to try and measure code coverage, but is that an effective use of developer time? I don’t think so, especially as trying to meet some code coverage goal is fraught with all sorts of issues. Apart from various good points on Stack Overflow, no shortage of people have blogged about the problems of relying heavily on a code coverage metric. I won’t repeat all the arguments, but I’ll give a few of my own.

    First, someone pointed out that you want to be sure all your code is tested. I disagree with that, especially in many  long dev cycle applications. There are all sorts of enhancements I’ve seen in many applications that never get used. While you should certainly check them for security issues, if the features aren’t being used, remove them. Since most of you don’t implement tests for security issues, I’m not sure there’s value in telling you to write a unit test for logic or functionality.

    The other issue with code coverage is that anyone other than a developer using this metric will put pressure on the developers to write more tests. Some developers may write good tests, but I wouldn’t be surprised to have tests written that always pass and aren’t checked for correctness. Tests like these are misleading and potentially create more bugs since anyone refactoring code might think their changes haven’t caused an issue if the test passes. Bad tests, IMHO, are worse than no tests.

    I do think that code coverage can be valuable. If a developer is looking to ensure that some part of their code is being checked, especially in long stored procedures, then code coverage can guide them to a place that might need  testing. Since most code needs more than one test, covering more than one case, code coverage doesn’t help. I’d prefer a developer spent more time thinking about how to build better tests (or experimenting) than looking at coverage reports.

    And if you need a code coverage report, try my technique for building one

    Steve Jones

    The Voice of the DBA Podcast

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