Voice of the DBA

Category: Editorial

  • A Tool is Better than a Script

    While working with a customer recently, I heard this sentence: a tool is better than a script. The reference was that this customer preferred a known, tested, approved tool for most of their staff rather than a script built, lightly tested, and perhaps changeable by anyone in their organization.

    I was surprised, because in many ways, I’ve depended way more on scripts, more often, than “tools” in my career. Often I struggled to find tools that actually worked in the way I wanted them to and built them myself with Unix shell utilities, VB Script, PowerShell, or some combination of those or other technologies.

    I asked them if they wouldn’t prefer to customize things and let one of their senior people write their tools. They said that it wasn’t necessarily a problem for a few people, but too many people might edit and change the script, even the senior people, and then others couldn’t depend on them. They weren’t sure if they were reliable if a known script wasn’t being run. Even among their senior people, someone would edit a script then they thought something wasn’t quite right, or there was a new requirement and then the script would return unpredictable results.

    I felt they didn’t completely trust their staff, but I also understand. I’ve changed my own “tools” and broken them or gotten back incorrect results. Depending on what the script did, and how busy I was, I might not even notice the problems. That might cause me problems if I expect data or actions to occur one way and they work differently.

    Scripts can be changed by anyone.  The results might not be what’s expected on a team. I get that. At some point in my career, I put all our DBA “scripts” or “tools” into a version control system and we had a path to the trunk (main) branch of them that was read-only, so that we knew what was being executed. If we wanted to change the script, we had to open an branch in the repo, make our edits, and then have another DBA approve the change before it would be merged into the main, and subsequently pulled into the folder in our path. This didn’t prevent changes, but it did give us some versions and history of changes.

    There’s a balance between flexibility and customization that is challenging to tread amongst team members. Sometimes a known, reliable execution is better than one that changes too quickly. We’ve been asked at Redgate Software to ensure people using Redgate Monitor can audit what actions are taken in the tool. Sometimes a team member changes a setting, such as an alert threshold, and other team members aren’t aware. That can impact their ability to diagnose problems when they assume the tool works one way, but it’s actually working another way.

    Tools we decide to use, whether purchased or OSS, won’t always do what we need. There is a requirement to build our own, but we also need some expectation and assumption of how they work. Especially in a team. I don’t want to have to re-read the code every time I run a tool; I should know how it works.

    At the same time, I can’t have every tool change each time someone wants something new. I love sp_whoisactive, but I depend on it working a certain way and wouldn’t want Grant to change how it reports data unless I know about the change.

    Working in a team requires teamwork, which means that whatever type of tools we buy/download/build, we need to ensure we all are aware of how they work.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Half of All Engineers

    The AI LLM boom seems to show no sign of slowing down. Each time I think we’ve reached some level of crazy use or predictions, things take another turn. I still find myself pinging back and forth between this will be amazingly good and horrifyingly bad.

    Sometimes on the same day.

    Today, I’m a little more down on AI. I was listening to Steve Yegge on the Pragmatic Engineer podcast, and they were discussing the curve of AI usage at companies. He points out that he’s mad that Amazon let 16,000 engineers go and might let more go. He worries that companies might let 50% of their engineers go. Not necessarily because the top 50% will be more productive with AI than 100% of engineers without it. Rather the concern is that companies will get rid of half their salaries to pay for the AI tokens for the other half.

    Steve Yegge is an accomplished software engineer that has worked at Amazon and Google. Steve wrote Gastown and has been someone who not only is successful at producing code but also thinks a lot about how we produce more software.

    How coordinated and powerful are the new models? Can they really do a lot of software work that we do today? Steve thinks so, but to be fair, he’s got a lot of experience and can architect and design software well, which means he can also guide AI LLMs and agents to write more code. He also thinks the latest models, like Opus 4.6, are way more capable that most people believe.

    I also caught this post on X about a paper predicting that AI might cause economic collapse as less knowledge workers are used in various tasks. This might happen faster than we can absorb those workers who are laid off in the name of AI back into the economy in other positions. It’s a scary thought.

    The positive side of this, at least from me, is that so many organizations move slower, and so many people aren’t extremely competent software engineers, so we’ll get a lot of bad software written by non-technical people that doesn’t scale. We’ll have more database (and application) performance issues, and that will slow the use of YOLO, vibe coding.

    Plus plenty of companies just aren’t implementing or looking to pay for lots of tokens. They’ll just move slower and the world will change, but not anywhere near the pace that Steve or others think it will. We’ll see, but let me know what you think.

    For a more positive spin, I’ve been reading Reshuffle, which is a little less depressing about the future.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Spring Connections and Learning at PASS On Tour

    It’s just a few weeks until the spring PASS On Tour Chicago 2026. This is a smaller version of the PASS Summit that will be coming to Seattle in November and has been running for 26 years each fall. Myself and many other data professionals have found immeasurable value from the time we’ve spent with others at these events.

    Connect. Share. Learn.

    That’s the motto that PASS adopted many years ago, and I love it. We get to network with each other, talk about our experiences, challenges, and struggles, and hopefully find a way past them. We are stronger as a team, and the synergies that come from people working together allow us to accomplish more than we ever would alone.

    The PASS Summit has been an event at which this has happened, and I’ve been very lucky to attend most of them. I’ve learned lots of tips and tricks in sessions, but much more by talking with others before or after the presentations. I’ve been inspired by others and warned about walking down paths where people have struggled. All of the knowledge shared with me has helped grow my career across the last 26 years.

    In 2025 there were 3 tour events, and I was able to attend all of them. They were small, but I still had ample opportunities to connect with others, learn from them, share with them, and get out to a few dinners with friends who didn’t plan on coming to Seattle, but they made one of the regional events.

    This year there is just one tour stop in the US. May 7-8 in Chicago, and I get to go again. There’s a fantastic lineup of speakers, some great pre-cons, all at a relatively cheap price compared to many other data events. Chicago is easy to get to and it’s not too expensive to spend a few days in one of America’s classic cities.

    I hope you’ll join me in Chicago. It’s short notice, but there are still chances to join, and I’ve got a discount code if you ping me 😉

    Steve Jones

  • Local Agents

    Recently I saw an interesting article, saying that someone could build a general purpose coding agent in 131 lines of Python code. That’s a neat idea, though I’m not sure that this is better than just using Claude Code, especially as the agent still uses the online version of  the Claude model from Anthropic to generate code or perform other tasks. There’s a video in the article showing how this code can be used to perform some quick tasks on a computer.

    However, the code isn’t specific to Anthropic. It can be used with any LLM, and I started doing just that, with a copy of the code from the article, but modified to use a local AI LLM running under Ollama. You can see my repo and feel free to download and play with it. It’s expecting a local LLM on 11434.

    I’m a big fan of local agents for a variety of reasons, but mostly because I know humans tend to do dumb things. Especially with new technology, and maybe even more especially in development areas.

    That includes me.

    I’ll take shortcuts. I’ll give an agent sysadmin on a dev database to try things. I want to be able to experiment, learn, and see what works. I want to learn how to use tools and fail using them. That’s how I get better. That’s how I get better in sports, in music, and in technology.

    And that’s not a project I can take time to work on. I don’t get to dedicate time to just learn and then go back to work. Work never ends. It’s a grinding, constant, continuous treadmill of things I need to deliver to others. I have to learn to experiment around those deliverables when I can find spare moments.

    With AI, that means we’ll do things that get InfoSec teams to cringe. I get the concerns over data transiting networks and going to who-knows-where to be used who-knows-how-by-others. I appreciate business subscriptions that guarantee that data won’t be used, but I also want extra safeguards at times. That means local models. Not necessarily on my laptop, but in my data center.

    Plus, that way I (or my org) can control the costs and manage expectations.

    I hope local models and local agents catch on, I hope more vendors support them and more organizations are willing to run them. Even in something like AWS Bedrock or Azure Open AI or Vertex AI. Then I can rent the latest and greatest hardware, but have more control over how my organization uses it.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.