Voice of the DBA

Category: Editorial

  • Speedy Break Fix

    I received a report at SSC of a missing toolbar in the forums. I checked, and sure enough, the toolbar for formatting code and text in responses was missing. I submitted a high-priority ticket, mostly because I hate unformatted code. The site was still usable, but people would be posting stuff that just didn’t look good. The developers got to work and had a fix, but it still wasn’t right. The wrong toolbar was showing. This was a generic toolbar, not the one that we have had for years (this one). They produced a second fix that contained the right toolbar.

    The developers are in and out of the SQL Server Central codebase, working for a few days on open issues, then busy with other work for a week or two. They work in a DevOps style environment, with changes run through a Pull request/peer-review process, then CI, then an automated deployment. They often can make a change and deploy it in hours, or even minutes.

    Is this a bad process?

    It would be easy to say that the developers were moving too fast in their deployments and not testing things. However, the issue in production wasn’t easily reproduced locally, and we found a few places where local dev environments don’t quite match live. That’s been an ongoing problem for as long as we’ve been developing software outside of production. The DevOps solution here is to adjust the environment setup in code so that dev does match production closer. I’d say this is my solution, but likely we’ll find something else in the future that isn’t the same and we will continue to need to adjust something to get the environments in sync.

    What’s the alternative? We could go slower and batch up a bunch of changes, testing them all, moving at a more waterfall-ish cadence. Would we catch this? Perhaps. However, we might not, and if we are batching changes, then bugs live for a longer time in production until we perform a new release.

    Or we could build a quick patch, in one of two ways. One is by moving quickly, at an agile/DevOps speed, to quickly build a patch. That’s a hacky, not-thought-through flow that many people use to fix a deployment, usually without the process and bounds that a good DevOps process provides.

    The other option is to bundle a fix in the next release, which could be next week? Next month? Who knows. Slow processes don’t necessarily make the final code better and can prevent rapid fixes.

    Ultimately my feedback from here to the project manager is that we need a test, a process, or something that checks for these issues before release. While I know something else could break, I prefer these small deployments taking place often, with bumpers to limit the regressions we know about.

    Steve Jones

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

  • The Great Developer Resignation

    In 2021, many companies had employees leave positions. The number of people resigning from their jobs was so high that the term “The Great Resignation” began appearing in many publications. A number of industries were affected, and there are no shortage of pundits and experts analyzing why. This happened primarily in the US, but the UK is concerned. This doesn’t appear to be happening in Europe, but there are concerns in Asia and Australia as well.

    The term feels misleading to me, as workers aren’t forgoing work. Rather, they’re changing jobs and looking for new positions, either at a better position in their field or leaving the field altogether. This is disruptive for firms, and costly, as finding new employees can be challenging and time-consuming. We also see a great loss to teams as the more talented employees find it easier to leave and replacing those people with less-skilled workers impacts their productivity.

    I ran across a couple of articles (US, UK) that talk specifically about the challenges when software developers leave. Many companies have realized the value that software brings to their business and feel the impact of the losses that come when they don’t (or can’t) execute on new application projects. The rush to DevOps is driven because better software and a smoother lifecycle improve the bottom line. Unfortunately, just as many companies don’t want to actually change and adopt better development practices, they often don’t want to change their culture, which impacts their ability to retain a talented workforce.

    It’s Friday, and you might spend a little time reading the articles and thinking about your position. If you feel you are good at your job and don’t necessarily enjoy the environment, workload, or compensation, should you think about leaving? Is now the time to ask for a better work environment? Should you look at companies that will give you remote work?

    The main question this week, which I know is hard to disclose publicly, is are you thinking about changing jobs? I expect few people to leave comments, but I’d ask you to think about your situation.

    We know that compensation matters, and many people find they can make a great living working with technology. However, there are other things that are important as well. Having a purpose that allows you to succeed at solving problems you enjoy, a culture that invigorates and stimulates you, autonomy to work on the things that your employer finds important, but in a way that suits you and your team. These are all items that attract talent. The reverse is also true, when you have a micro-managing, blameful culture where lots of uninteresting work is mandated. Those situations repel workers.

    As we come out of the pandemic, and organizations struggle to decide how to handle the future of offices and workplaces, there is a lot of power in workers’ hands. The last two years have shown that most of us can work remotely and get things done. We have the supply of skills that can’t meet the growing demand, and this is a good time to think about finding your dream job. If not the dream, then one that might be better than your current one.

    I have an amazing job at an amazing company, but not everyone does. If you enjoy your position, then good for you. You likely have more security now than ever. I know if I were still working for a few of my former employers, I’d certainly be setting myself up to find something as wonderful as I have now.

    Steve Jones

     

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

  • Think Marathon, not Sprint

    I saw an article about automating responses to security issues being a marathon not a sprint. The articles gives a few examples of different levels of automation response to situations, noting that each of this is a different level of maturity in the organization. At early stages, the response is mostly alerting a human to take action. Later, the automation will make some changes, but still defer to a human for more actions. The final example is automation handling most of the issue itself. Note, none of this means humans are unaware of what responses are being made.

    The idea is that improving security with automation is something that takes place across time, as the organization matures and becomes more comfortable and trusting of automation. It’s a marathon, where we push, but we know this will take some time to get to the end. It’s not a sprint where we make a quick fix and get a result.

    Actually, I think a lot of things are marathons in the technology area. That’s if we are looking to improve how we work with automation. If we like just firefighting issues and building quick patches, then we’re constantly sprinting.

    A lot of the work I do in advising clients about DevOps is to get them to think marathon. There isn’t really a finish line, but we are racing our competitors and trying to improve how we work. We just need to recognize that this is a process that takes months, not minutes. We want to mature and evolve processes, making them better over time. We also start small with our scope, hoping that we expand things to the entire organization over time, but again, that time is months.

    This was my same approach as both a developer and DBA. Find something that I can automate to make better, start to improve it, learn from success and failure, and repeat. At some point, I usually found something was working well enough to move on to a new area to improve. If I needed to come back and continue to improve something, I could do that as well.

    I don’t like sprinting. In real life, or in technology. I prefer to think marathon. We are pushing to achieve something, but with the further away future in mind, not the next few minutes.

    Steve Jones

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

  • Making Video Chat Better

    I ran across an article on Zoom fatigue and new tech that was written in July 2020. That month seems like ages ago, and at the same time, not too long ago as the world seems to have still been in some sort of suspended animation for much of 2020 and 2021. However, one thing that has remained since that time is a regular stream of Zoom and Teams meetings that I attend.

    I’ve been dealing with video meetings for over a decade. For most of the time I’ve worked for Redgate, I’ve had regular meetings every week with various people that are in Cambridge, UK. I’m in Denver,  US, and while I enjoy going to England and visiting the office, that’s a few times a year. Across the years, we’ve tried a number of platforms, and various different configurations, including a dedicated conference room with extra mics and sound-absorbing padding on the walls. None of this made for a great experience, though I have to say our adoption of Zoom across the last 2-3 years has been the best experience overall.

    Still, when I have multiple meetings in a day, I feel fatigued. Many people feel similarly, and that has not gone unnoticed. While we do try to cut down on some of the meetings as a company, they aren’t going away entirely for us, or likely, for your company. Some companies are going back to the office, at least part-time, but many employees are resisting, which means we need better tech. Something I hope is coming.

    The article I linked above talks about some of the changes taking place, with some newer tech being tried. I don’t know I’ll ever like video chat without some sort of VR-style view of a room or holograms, but perhaps something will come along that makes these meetings better. I’ve certainly found that having larger views of speakers is good, but when they rapidly switch from one person to another it feels like a 5-year old directing a live TV show. I want to turn off my video and just listen. Or end the call.

    One thing that I’ve found helps is I try hard to get more done through Slack and email, avoiding meetings that aren’t needed. The best way to combat something that doesn’t work well for me is to do less of it, so I work to minimize video, type more, and hope for more live face-to-face meetings a few times a year.

    Steve Jones

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