Voice of the DBA

Category: Editorial

  • Republish: The Cost of Switching

    Still on vacation. Enjoy The Cost of Switching

  • Wasted Work

    I’ve been re-reading some of the manufacturing and DevOps books that I’ve collected over the years. In these texts, there are a number of concepts that stand out, but one that resonates with me is the concept of waste. There’s actually a good article on LinkedIn about waste that’s worth reading as well. While it’s easy to start spinning in circles and thinking everything is waste around you, step back and keep some perspective that some waste is inevitable because the world is messy. Don’t get too caught up in waste, but try to reduce waste where you can.

    One of the areas that I think contains a lot of waste in software development is the effort to build features that won’t be used. Like many of you, I have been asked for no shortage of changes to software in the past. Often those changes require both application and database changes, usually to support a new way of conducting business.

    The interesting thing to me is that often I’ll work my through a queue and get changes completed, a percentage of which rarely, or even never, get used. What seemed like a good idea when it was requested, specified, and scheduled may not be a good idea weeks or months later.

    In other cases the latest request is labeled as important and needing to be completed ASAP. This might displace older work, perhaps even pushing it to the lowest priority level where it may never get completed. That’s fine, as if the work isn’t important enough to be pushed by someone, perhaps it isn’t needed.

    To me, this is one of the advantages of working in a DevOps style flow, with small changes being developed and released. If clients start to use the feature and need additional development, we can continue to enhance the feature. If the users don’t use it, which we know from either future requests or instrumentation (the latter is preferred), then we can put more effort into the areas that are more important to our organization.

    With less waste.

    We don’t work on large projects to completion, wasting work on the parts of projects that will not be used. Instead, we complete small parts and keep shifting our focus to the areas that are most important to clients.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Break Problems Down

    Recently I was pouring over a few questions in the forums and noticed something that I would think is obvious, but apparently it isn’t so for other people. A poster was attempting to run a query across multiple databases and needed help structuring code to work in the context of each database. The poster was going back and forth a few times with others that were attempting to help them, struggling to get suggestions implemented into their code. That’s typical, as someone that needs an answer often doesn’t understand the solution and is learning. In this case, I found that the original poster was losing some of their troubleshooting skills in the process.

    Years ago I read a piece on Simple Talk from Kathi Kellenberger. She is now the current editor of the site, but at that time she was just a SQL Server MVP and expert that was looking to help others learn more. The article was called Solving Complex T-SQL Problems, Step by Step, and it stuck with me. There wasn’t any knowledge that I didn’t know, but it was an organized explanation of the Kathi’s steps that I found refreshing. This was a nice reminder to me to not move too fast, but ensure that I really understand what the problem is and work in stages.

    I’ve certainly been guilty at times of moving too fast and glossing over some details. That might be fine in some cases, but if I produce code that’s doing that, likely I (or someone else) is going to be rewriting code later. That’s not what we want to do, especially if this is a logical error. I might understand some less than optimal code from a performance perspective, but there shouldn’t be logical errors.

    In this case, the poster had incorporated some changes into code and kept running the entire script, getting bad results. They even started to pinpoint a few areas where data wasn’t correctly being returned, but couldn’t solve the issue. This was a somewhat complex script, and it could be easy to miss some mistakes. This was also a dynamic SQL script, which often means that we have to extrapolate from our code to understand what the engine will actually execute. There’s often a simple solution to help you break the problem down: use PRINT.

    I’ve done this for most of my career, in many languages. Even today, I sometimes use this in PoSh to ensure that I’m not missing something being done. Watch windows and other debugging tools are great, but they sometimes are more difficult to understand when there are long strings of data. Print often simplifies the process.

    No matter what tools, languages, problems, etc. you are working on, breaking things down is often the best way to tackle a complex task. You might be surprised how much clarity this can bring to a tough problem. Even if you need to ask for help, having a list of things you’ve tried, and some data on the results is very much appreciated by those you ask. That way they know what you’ve tried and what to recommend.

    Steve Jones

    The Voice of the DBA Podcast

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

  • In Memorium

    I’m getting older, and as I remind people when I talk about careers and balance, I likely have less life ahead of me than behind me. I think about that as I try to enjoy life and appreciate the good and bad things I experience. I’ve had a wonderful life, and I can’t complain about anything. I wish everyone could say the same thing. My apologies in advance for the tone of this editorial.

    This week I added a new category to the Database Weekly newsletter: Obituaries. I had Andy Warren suggest this earlier in the year, but I neglected to do it then, mostly because it’s a sad reminder of loss. This past week we experienced another loss in the #SQLFamily, with the passing of Naomi Williams on Oct 30. There is a memorial fund set up for her children. I only briefly knew Naomi as a fellow speaker and the organizer of SQL Saturday #550 – San Antonio, but I enjoyed her enthusiasm and joyful nature.

    This wasn’t our only loss this year. Tom Roush passed away on Jan 30, 2018 (his book of stories is available). Robert Davis passed on April 2, 2018 (memorial fund), and I found out this week that Aaron Lowe had passed on July 23, 2018. I’m sure there are others, and while I don’t want to learn we’ve lost others, I’d appreciate anyone letting me know so I can remember them fondly.

    Life goes on, and we all must deal with losses. Those increase as we age, and that’s becoming a regular occurrence as days pass by. Whether it’s someone I’ve shaken hands with or an individual famous in for some aspect of their lives, death is something that I see far too often.

    Many of these are sudden, unexpected, and unpreventable. However, a few aren’t, and I’d like to ask all of you to ensure you help others where you can. Suicide has taken a few people I have known, and if any of you are struggling, please seek help. If you know someone struggling, please refer them to a suicide hotline. If any of you ever need to talk, I’m here as are many of your friends and family. We have enough tragedy in life, so please don’t withdraw completely.

    This is a sad week for me, but I’ll toast to my current and passed friends at the Summit with fond memories, enjoying the moments we have and and will have in this life.

    Steve Jones

    The Voice of the DBA Podcast

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