Voice of the DBA

Category: Editorial

  • Choose the Second One

    I wonder if any of you have ever tried this. When faced with a problem, think of a solution using whatever comes to mind. For most of us in the data space, this is a SQL-based solution, hopefully a set-based on for MSSQL. For Oracle, you might approach things differently. In any case, solve the problem.

    Then force yourself to imagine that you weren’t allowed to implement the first idea for some reason. No funding, no time, whatever the reason, you can’t implement it. Maybe it’s your team hates your ideas and just won’t approve the PR.

    Now, come up with a second idea. Something new and different. This might be harder in the data space with SQL than in application programming (C#, Java, etc.), but the idea is expressed in A Philosophy of Software Design by John Ousterhout. It’s how he has often taught his software design course at Stanford. His approach is to force students to think more deeply about their design, and he often finds that they build a better system the second time.

    Hard to do, but arguably a good idea. He talks about this in this podcast with the Pragmatic Engineer, and how many smart people underperform when building their software. He says it doesn’t necessarily take more time to do this twice, which I am skeptical of. This might be easier for students, but in the real world, is it even practical? Often we’re not working on very hard problems; we’re working to implement something that needs to get done, and often isn’t that well-defined. In fact, many of the things I find developers are asked to build things that either aren’t well thought through or are relatively trivial. There might not be a good second solution for a lot of vague ideas whose value is unclear.

    I do think that often we go down a path that quickly becomes complex. Engineers will start to overcomplicate things, so perhaps slowing down, spending a short period of time thinking of a second solution, debating another approach with others is worth a little time. Maybe you wouldn’t implement it, but at least think it through and game out the approach with pseudocode.

    I haven’t run into anyone who approaches software this way on a regular basis, but if you do it, let me know. If you think it’s a good idea, maybe it’s worth trying at the beginning of the next sprint when you tackle a new design requirement.

    Steve Jones

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

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

  • Republish: Data Decisions or Instinct?

    I’m off today on a cruise ship in Rome for 10 days with my wife. I’ll be out of touch, and hopefully my colleagues can handle the load while I’m gone.

    You get to re-read Data Decisions or Instinct?, which is something I’ve been questioning a it lately. I’ll write about it, but as you read this, think. And then check out the first comment from 2014. I’m reading that book now.

  • Smart AI Agents and Data Security

    I don’t know if Anthropic, OpenAI, or Google have really spent a lot of time and effort on security around their models. I know they talk about it (Anthropic, OpenAI, Google), but in practice, I’m not sure the researchers and testers are being as careful as the marketing and management of those companies want you to think.

    Gemini broke into three companies during a security test. Claude escaped a test environment and breached three organizations. OpenAI had breaches of Hugging Face and other sites, so perhaps this is the most powerful model, as it exceeded the “rule of three.” In all these cases, the agents weren’t doing anything amazing. These were acting the same as most malicious or bored human hackers who might find or guess credentials and take advantage of them. In some sense, this points to the generally poor state of security in the world.

    On the other hand, it could be that these high-tech organizations aren’t equipped to secure systems from the rapid, capable digital fingers of agents powered by a model. If they can’t, then to what extent can we be expected to secure internal AI agents in our organizations?

    For those of us who secure and manage data assets, do we think that our systems are well secured? Do we think our legitimate users, to whom we’ve granted access, are securing their credentials? What is the likelihood that we’ll have an internal breach from an agent that’s asked to find some data and discovers a) unsecured credentials in a file or repo, b) finds production data it can access in a non-production, less secure system, c) a backup of a database not protected that the agent can restore, or d) some other hole?

    I do think AI has a lot of potential, but it operates in a somewhat slapdash, reckless fashion. I’m not convinced most vendors (or models or software incorporating AI) will provide robust and comprehensive security controls. Even if they do, how many of us will know how to implement them well? Heck, we see developers and DBAs mess up SQL Server security on a regular basis, and I think that’s a simple system to configure.

    I’m excited by AI and also terrified of the possibilities.

    Steve Jones

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

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

  • Today’s AI

    “This is the worst version of the car you’ll own.”

    That was a quote from the delivery manager when my wife and I picked up our Lucid Gravity. He said that since the car is very software-oriented and gets regular over-the-air updates, the car keeps improving. The car I bought is the worst version because it keeps getting better. His experience over the last few years with the company has shown that the changes made in software result in customers growing more fond of their vehicles.Today’s editorial: Today’s AI

    Or maybe they’re less annoyed by things that don’t work well. Ah, the joys of software.

    I was reminded of this interaction when I saw someone send a note at Redgate about AI with this quote: “Today’s AI is the worst AI you will ever use.”

    Is that true? I guess, to the extent that we think the AI model you use today will improve and its capabilities will grow, that might be true. Certainly, the move from Sonnet 4 to 4.5 to 4.6 to 5 seems to be, well …

    The same to me. Has the model improved? By benchmarks and measures, it has. The same could be said for the GPT models from OpenAI. However, I don’t know that I have found much difference. Depending on my guidance, I think I’ve found that I’m as likely to get great results as poor ones from different models. I’ve tended to stick with Sonnet models, though often for the focused tasks I pick, the Haiku models work, as do the Opus ones.

    I’m cheap, so I don’t often see the point in using Opus. I haven’t found it to be clearly better, though; to be fair, I’m not letting it loose on large tasks, and I am conscious of costs. I’m not paying, but I tend to treat all things I do as if I were paying the bill myself. That helps me to be aware of when I am being effective and efficient.

    When I’ve seen my cars upgrade (first a BMW, then a Tesla, now a Lucid), there have been clear changes that I’ve appreciated. There are sometimes annoying upgrades, which always remind me of Jeff Moden: Change is inevitable… change for the better is not. That can be true, but I find that the changes made in software often make sense, and I can see how they an improvement. Even when I don’t like them.

    For a non-deterministic model, however, I don’t know how easy it is to measure change, and if the model is “smarter”, but I don’t use the extra smart-ness, is it better? I have no idea how to measure these improvements, and I am certainly skeptical that these benchmarks and the frontier model hype is driven more by the need for profit than by a better AI model.

    Steve Jones

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

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