Voice of the DBA

Category: Editorial

  • 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.

  • Why Don’t You Unit Test Code?

    First, I’ll apologize to those that do use formal, automated tests in advance. I’m not really writing for you, and I’m sure you can teach me more about testing. Perhaps you can comment about how and why you do this, or even write some articles to help others.

    For everyone else, why don’t you test in a repeatable fashion? Let me know with a comment today.

    One thing I’ve noticed as I’ve talked DevOps and testing for a number of years is that so many developers agree testing is a good idea, but claim they have no time, no support from management, or no need to repeat tests once code is written. Sometimes I hear all three excuses at the same time. The same people will also admit that they have problems with code at times, and that quality could be improved.

    Perhaps it’s me, but I’ve never had my boss sit there and watch me code. He or she doesn’t know how I might write code. I certainly write a query, run it, and look at a bunch of rows and see if I think the code is correct. Perhaps I need to run other queries to verify values in the results. However, I could also build a quick test with something like tSQLt, like the one I set up for checking COALESCE that does the same thing. With my unit test, I can run it over and over, modifying the test as I discover new edge cases to validate. Which way do you want to write code?

    Even if I have a set of data I need to assemble, it doesn’t take much longer for me to write a test, especially when I need to also solve the problem. I find that putting a test together forces me to slow down and think about the rules for my code. Since I need to come up with some result set, building that into a test of some sort is fairly easy and let’s me double check how I think data will change. I can then repeat the test over and over as I modify code. I can even grab sample data from production and use that as the basis for my unit test if I need to check a specific entity’s values.

    I know many things I write in SQL might not be worth a test. Often the simple CRUD queries and basic aggregations aren’t things I’d test, but when my query becomes complex, includes APPLY or outer joins, and logic to decide how to filter or format data, wouldn’t a unit test make sense? What about if you want to be sure you’re processing the correct rows from a large CUBE or ROLLUP operator? Certainly if I’m fixing a bug, writing tests makes sense, at least I think so.

    Let me know what you think today.

    Steve Jones

    The Voice of the DBA Podcast

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