Voice of the DBA

Category: Editorial

  • Changes, Happiness, and a Few Tears

    Change is inevitable for most of us. The jobs we hold, the places we work, the people we know, even our families grow and change over time. As I get older and live longer, I’ve learned to accept, appreciate, and flow with changes. I might resist, delay, embrace, or anticipate tomorrow, knowing there is always a positive and negative side to things.

    This week, one of my colleagues retired. Annabel has been a part of Redgate nearly as long as I have, and we’ve worked together for many years. If you’ve ever attended a Redgate event, live or online, she likely had a part to play in the planning, organizing, execution, financing, and every other part of the process.

    My colleague, Allison, made a wonderful post yesterday, on Annabel’s final day with memories and thoughts from their time together. I wrote my own post with pictures and memories of our time together. There are so many more, and every time I think about our history, I’m touched, blessed, thrilled, and sad.

    At PASS Europe last week, we said goodbye to Annabel at the last event she’s worked on. We toasted, laughed, and cried. She shed tears, which is a rarity, but Grant and I probably cried the most. She’s been a part of our lives and careers for many, many years.

    Even typing these words brings tears to my eyes.

    The future brings opportunity and excitement. It also brings sadness and wistfulness of the past. I can enjoy the memory of what I’ve experienced, miss the way things were, balancing those feelings with the my view forward to what is coming.

    I can also think about what didn’t go well previously. We’ve had some issues at events, challenges, stressful times. Both at events, and while working with others in technology. I can learn from the past, be proud of the war stories, be glad we got past the failures, celebrate our successes, and plan to do better tomorrow.

    The thing I miss most about growing older and moving forward are the people who I enjoyed spending time with. Those are the memories that stick with me more than the projects, the successful tech solutions, the elegant and fast code, the awards, bonuses, and achievements.

    I miss the humans who have touched my life, and hopefully, whose lives I’ve touched.

    I wish Annabel the best in retirement, I’m excited for where she journeys tomorrow. I hope those of you reading this make, cherish, and enjoy the great friends in your life.

    Steve Jones

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

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

  • Follow Your Hunch

    For a while, I kept seeing that the cost of writing code was approaching zero. So many people felt that with an AI LLM, the costs would go way down to produce software. I’m not sure that’s true. In fact, some companies are finding they spend more on AI tokens than salaries.

    However, the ability to produce more code, experiment with ideas, or generate proof of concepts has gone up. Whether it’s worth the cost or not depends on the engineer, but some organizations are finding that they can try more things than they would ever had time to try in the past. The time of engineers was the constraint, and if you can afford the cost, AI LLMs can relieve that time pressure.

    Maybe the ability to get more done with agents means you should follow one of your hunches in software. Maybe you should try something.

    Be thoughtful in your approach, use the LLM wisely, and learn to guide it efficiently, but use it to try an experiment that you might not think you have time to explore. Try an alternative. Implement something in a new way. OR implement it yourself and set the AI loose, asking it to work in a different way. You certainly could tell the LLM not to use your approach and try something different.

    To me, the big advantage of an AI agent is it gives me time, something that I see as the most impactful constraint in my life. I’d like to get more done, but I’m not willing to work a lot more. Using an AI agent with a measured approach lets me tackle things that I might not otherwise get done. Certainly not as quickly as I get them done, and certainly not without stealing some personal time.

    I get more done at work, without working more. I’m not working less, but I’m more effective. That’s what I’ve always aimed to do.

    Steve Jones

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

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

  • The Slow Growing Problems

    Both as a DBA and developer, I’ve had plenty of immediate, this-is-broken, fix-it-quickly issues. Usually, I, or someone else, wrote some bad code and somehow got it deployed. I mean, I do test things, and I would (probably) never change code after I’d tested it to fix that one little annoying thing, like the formatting. I’d (almost) never do that, and I’m sure you wouldn’t either.

    Yet somehow bugs slip in at times.

    Those are the acute issues, and they can be hard to fix at times, but often we can reproduce the problem in development and build a fix. Sometimes we even spot the issue quickly and just fix it in production. I’m sure you never do that, but I have had that experience myself a few times.

    However, in the database world, we can have other, slow-growing problems. I saw this post from Jacob Sebastian about production issues that don’t trigger alarms. There are just slowdowns that trickle across multiple systems and cause issues for clients. These aren’t things you instrument for, as a slowdown isn’t necessarily an issue. These things can resolve themselves, or they can develop into a major issue.

    I think about this like vehicle traffic. A minor fender bender on a highway might not be a problem, but it can become one. Cars don’t get out of traffic quickly enough, or traffic police don’t arrive soon and move the cars. Traffic starts to back up, which slows down the response, including that important tow truck that might keep things moving. Suddenly, it’s not a few people inconvenienced by an accident, but thousands.

    There are likely signals in your environment that would let you know about a potential issue coming soon. These are subtle and not always indicative of a problem individually, but taken together, they indicate a production issue is going to occur. To me, this is a place AI can eagerly be taught to look for these signals and then happily keep looking for them every day.

    The future of monitoring is the active examination of correlated data that precede an issue, hopefully giving humans, or other AIs, enough time to respond and prevent customers from experiencing a slowdown.

    I’d certainly welcome this in both traffic motorways and database systems.

    Steve Jones

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

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

  • Liability for AI Errors

    This week there was an article that speculated that doctors in the UK could be liable for errors made by AI tools unless rules are changed. The argument is that AI tools should be treated as products, which isn’t necessarily the case right now. Right now doctors may face all the liability instead of AI tool makers having some responsibility. From my reading, this doesn’t appear to say that doctors aren’t still accountable for mistakes, but they aren’t wholly accountable. The Medical Protection Society wants the technology vendors to bear some responsibility.

    I have to admit I’m torn here. If doctors are using tools, they should be sure the tools work well and they agree with the recommendations or results. However, I think AI changes things somewhat. If I read a medical device, say one that analyzes blood, I expect that the results are deterministic and accurate. If they aren’t, how could I, as a doctor, know that. The companies the built (or maintain) the device would be culpable for errors.

    Using AI assistance, however, is a little different. This is a non-deterministic interpretation of data. In the same situation, if an AI were to interpret blood results and summarize them, perhaps failing to point out a deviation of a value and this impacted patient care, is the AI responsible? The doctor for not realizing there is an issue? Joint responsibility?

    I think it’s unclear. I’m not 100% sure how I feel here, and I lean towards both being liable. If someone is training an AI model to help with medicine, then they ought to bear (and feel) accountable for results.

    This seems different than software engineering to me. In medicine we have humans overloaded and AI is supposed to help, but has to be responsible. I don’t think the stakes are as high in producing software. It’s an arbitrary decision to say we need to get xx work done with yy resources. AI can help, perhaps amplify the abilities of people to produce code, but the people still have to verify the AI results. Any time pressure is a decision we make, not one brought on by medical issues.

    Perhaps this seems hypocritical, and I will admin I’m not 100% sure how I feel, but I’m more concerned with AI technology bearing responsibility in healthcare than software. Do you feel the same way? Or perhaps in either case the AI is just a tool? Let me know what you think,

    Steve Jones