Voice of the DBA

Author: way0utwest

  • Psychological Safety

    One of the biggest challenges to becoming better at building, deploying, and operating software is the culture changes required. DevOps requires we work as a team, which can be hard to do. Often people have competing interests and goals. They don’t trust each other as much as we’d like, and maybe more importantly, management doesn’t trust the people doing the work.

    There is plenty of blame thrown around when things don’t work as expected (or aren’t delivered). That’s a poor culture in which to be creative or experimental. In reality, those things are a lot of what we do in software development. We aren’t solving the same problem over and over, building a bridge or house that is mostly constructed as many others are. Instead, we are assembling more complex systems in different ways.

    Most of us aren’t building airplanes, but the situations and problems in this article could easily be applied to many software development projects. Ambitious sales, targets set by management, not engineers. A lack of listening to feedback and unstated pressures to just push things through the system, regardless of potential issues. Perhaps the only thing I agree with from Boeing’s side is that they can’t find all defects, just like we can’t find all bugs. However, we can often find many and minimize or eliminate the impact of the critical ones.

    The pressure on Boeing engineers and line workers is similar to those in software, both on developers and operations. Development needs to deliver features, whether well-tested or not. Operations need to get these out, regardless of the impact on the system. It’s a gross generalization, but one repeated over and over in a few places I’ve worked.

    Culture is critical. Part of DevOps is frequent deployments from a faster speed of deployment. However, that’s only one part. The other is that we continually learn and improve how we do things. We raise the bar of quality. If we are only focused on moving forward without getting better, we get into the position that Boeing was in. No trust, no psychological safety, and no attempt by management to implement DevOps culture. Instead, they’re just pushing for more features with (hopefully) more automated testing, but no real impetus to ensure this is the case.

    More and more of the world is run by software. Whether this is in cars, restaurants, or government. When software doesn’t work well, there can be substantial problems that not only impact a bottom line, but can prevent people from getting goods or services they depend on. I know many of you that build and operate software try to do a good job, and I hope you know this means polishing your craft and improving your abilities. I also hope that management will learn that their support in improving quality is as important as the drive for more features in software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Daily Coping 9 Nov 2022

    Today’s coping tip is to make time for a friend and have a coffee, meal, or just spend time.

    It’s been a busy few months for me. Since Sept 1, I’ve been away from home for 5 trips and 30 days. I leave in a couple days for another one. This has made life a little hectic and frantic, as I’m trying to juggle many tasks with limited time.

    I made lunch plans with a friend a couple times and we ended up cancelling, each of us getting busy once. We lined up a third date between my trips, and even though I was busy, I decided to keep the plans. I’ve neglected some Denver friends, and I needed to stop that.

    My wife questioned whether I had the time, which was fair. I was busy, and this lunch meant I’d be working late that night, but getting some time with a good friend, recharging my mental state, and taking a break were important.

    I’m glad I did it.

    I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

  • Challenging Yourself

    I saw this posted on Twitter recently: “If you’re always right, you’re not learning. If you’re never failing, you’re not reaching. The objective is to be right. The objective is to succeed. But if you’re always winning, you’re undershooting your potential.” –@JamesClear

    I found that to be a very interesting view, especially as I think about moving my career, life, business, or anything else forward. I think about this in terms of the goals I’ve set for myself each year for work, or each season of coaching. In the past, I’ve sometimes tried to pick those items that I think I can accomplish.

    After all, it’s nice to check off everything at the end of the quarter/year and note I did everything I planned to do.

    However, is that playing it safe? Since I know roughly what my workload is, how busy I expect to be, am I just picking things that aren’t pushing me to do better? Or perhaps more importantly, should I be optimistic, push, and if I fall short, examine reasons why. Life sometimes changes in unexpected ways, and I don’t always have control over what things might come up in my schedule across a year. Heck, I might not anticipate everything that comes up this week, or even today.

    When I set my goals, I try to review these monthly and examine what I’ve done. Usually, across a year, I realize that some of my goals feel less important across time, or that they are such a low priority (nice-to-have’s) that other work or life constantly is more important. There also is the case that my mood changes and sometimes I just don’t want to do some things and keep procrastinating.

    My life often looks different in May than it did in January. It looks even more different in November, and as I write this, I think back to the decisions I made in January. I can barely remember the why, which is probably another hole in how I challenge myself. I ought to set out a basis at the start to remind myself of the reasons for these goals when I look back periodically when I assess my progress.

    I ask others to push themselves, so I ought to do more of that myself. Taking on a challenge is a good thing, and since life is more than work, I am looking forward to finding a better balance of challenging how I look to advance my career, as well as my personal life, and pick a variety of things that are both important to me, but are also in keeping with the spirit of balance. Time with my wife, hobbies, friends, and even myself are important as well. I don’t look to schedule those, but I do want to remember that while I want to challenge myself, I also need to balance that with living and enjoying my life.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • T-SQL Tuesday #156–Ready for Production

    tsqltuesdayIt’s a busy time for me, but it’s also T-SQL Tuesday blog party day. I’m rushing a bit as I forgot about this (thanks for the reminder, Deb) and had to help on the ranch this morning.

    In any case, a moment of Zen.

    20221108_082454

    Now, for the T-SQL Tuesday post to answer Tom’s invitation.

    The Quality Bar

    Lots of code gets through to production. I suspect many of us agree that not all of this is production quality. Often we find issues with code that doesn’t perform well or even meet the specs of what we required.

    I haven’t had to put much code in production in the last decade, but I do remember doing so, and I remember supporting code. To me, the code quality that defines production is this:

    Does it make my phone ring?

    If the answer is no, it’s production quality. If it does, then it’s not. That’s how I’ve worked on things in the past, and it’s served me well.

    You might argue, Steve, that doesn’t help. How do I know what code will meet that metric? There’s no easy answer there. You need to know the system, the requirements, the clients, and the workload. There is a lot that goes into deciding how to build code and what commands, structures, architecture, etc. is suitable.

    A few examples. In SQL Server, we avoid cursors because they are not efficient. However, if I have very rare processes, or sometimes on-offs, a cursor might work fine. If it doesn’t overload the server, runs fast enough, and gets the job done, why not?

    Another example is using CTEs to pre-aggregate some totals so that I can write a simpler query for a report with related data that isn’t aggregated. This might not be very efficient, and might create a lot of logical reads. However, if the report isn’t a problem with the server workload, is it production quality? I think it is.

    The caveat to this is you also need to know data growth. What is production quality today might not be in a year. Potentially we need to refactor code later. That’s fine for me if the situation changes, but it’s not fine if I can forecast this being a problem and I have a better technique, perhaps with some WINDOW functions and less CTEs. I don’t want to defer work unless I don’t have a choice. If I can write better code today, I should.

    This also means I ought to be learning more about how to produce better code from others on a regular basis.