Voice of the DBA

Category: Editorial

  • A Worse Computer; A Better Car

    A few weeks ago, my wife and I purchased a Lucid Gravity for our second EV. We’ve owned a Tesla for almost five years, and it has been an amazing car. However, we decided that we spend a lot of time driving, and we wanted something a little more luxurious. The Tesla has a bit of a stiff ride, and it’s not quite as lush a car as some others EVs that have come out since we bought our Model Y. After trying a few different brands, we were excited by the Lucid and decided to get one.

    Like the Tesla Model Y, this is really a computer on wheels. A lot of software and screens drive the vehicle, though it’s not quite as minimalist as a Tesla vehicle. There are physical buttons and controls in various places, and more than one screen. Some things work better, and I like that.

    However, some things are worse. While researching online to learn about the car, we saw someone post this: The Lucid is a better car, but a worse computer. The Tesla is a better computer but worse car.

    I agree with that. One thing I’ve learned in owning two and other modern computerized vehicles is that software is hard. Even something as basic as Bluetooth can be a hassle and operate inconsistently in different vehicles. I’ve also learned that product managers and engineers don’t always think deeply about the end-user experience. Perhaps the Lucid developers are under pressure to get features out, but it seems that I’ve encountered more than a few things that could (should?) have been built differently. Or would have if a little more thought were given to the end-user experience, especially given how easily software can be configured with toggles and switches. I’m always amazed when more things aren’t switchable in software.

    Yes, I know software takes time, and it is hard. My tenure at Redgate has given me appreciation for the challenges of deciding what to build, test, and release. I’ll write about some of the Lucid decisions on my blog, as there are a few things from the software development perspective that make me scratch my head. It’s not just me, as I’ve known people who have had Fords, Cadillacs, and Volvos who complained to no end about their teething pains with the software.  A few were ready to abandon the cars. I don’t feel that way, and I know I’m an early adopter. I have some tolerance and patience for the things I think aren’t built well.

    Overall, the car is amazing, very comfortable, and brings a smile to my face, but there are a few software conveniences I got used to in the Tesla that are missing in the Lucid. It’s definitely a worse computer.

    But a much, much nicer car. And, as the delivery guy noted, this is the worst version of the car I bought. It will only get better over time.

    If you think about a Lucid, use my referral link. We’ll both get some credit.

    Steve Jones

    at Libsyn, Spotify, or iTunes.

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

  • Building Great Software

    Most of us will work on software for our organization, and we might not want to or care about the end result being great. We do want it to work, and we want clients to find it useful. If we have external customers using our systems, maybe we want it to be great. In most of my experience, people are often proud of their work, sometimes ashamed, but not many people spend a lot of time making their corporate applications great.

    Often because we don’t have (or aren’t allowed) the time to do so.

    Basecamp is a popular SaaS project management solution, and Hey is a reimagined email service that many people love. One of the founders of the company wrote an interesting post on software being built that starts with this sentence: “The speed at which a product is developed doesn’t inherently make the product better or worse.”

    It’s a bit of a shot at AI, but it also goes into the fact that we often measure our software process in ways that aren’t about the output. Most organizations have abandoned lines of code as a metric, but I do see commits or PRs being used, as well as other metrics. Trying to decide if your developers are effective isn’t a horrible idea; after all, we should be ensuring that they are getting something done, but none of those metrics necessarily help us make better software.

    I see that at Redgate, as we incorporate AI into our work. A lot of the things that make software take time aren’t solved with AI. They’re solved with deep understanding of the problem space, what your customers need, and what helps them work well. AI accelerates some things, but we still need product people empathizing deeply with customers and designers watching for UX issues that create friction for customers. AI can help speed up the experiments and outputs in some ways, but just adding in chatbots or AI agents that write code isn’t necessarily useful.

    There are a lot of decisions in building software. What to do, what not to do, what’s more important than something else, and of course, what approach to take in the architecture. That’s before we even get to performance, which is something that far too often gets ignored, at least for the code being run against databases. Building great software is hard, but it can be done, and AI can help.

    You just need talented humans guiding the process.

    Steve Jones

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

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

  • Imagine the Physical World

    Brent Ozar has a series of database animations posts, where he tries to explain what work is done by SQL Server during certain operations, such as Index Seeks and Page Splits. These show how the engine might need to read or update various pages as it tries to perform operations. Both experienced and novice SQL Server people might think that these are interesting, but not that useful.

    I think they’re great.

    For most of my IT career, I’ve drawn parallels between what I’ve asked the computer to do, and how this might play out in the real world if we weren’t working on digital systems. Most of the constructs we have, connecting to a system, sending a query, configuring a firewall, sorting data, etc. can be related to a physical action.

    If you want to understand page splits, imagine you had the index from a book printed out (or a TOC), and broken out across multiple pieces of paper. If I asked you to insert something in the middle, or to lengthen an entry that doesn’t fit, what would you have to do? You’d need a new piece of paper, you’d put it in a place between the others, you’d copy over some data, you’d erase some data from existing pages and more. Exactly what Brent’s animation shows.

    That’s real work.

    The more I think about the work the computer does, even if it’s measured in ms or ns, the more I can think about whether I can find an efficient way to complete my task. It’s not that I mind the computer reading 1mm rows (or 100mm), but if I can reduce the work, I reduce the latency, the computer, the disk, the cost, the everything. My customers are happy when I try to reduce the work and make everything run faster.

    This view has helped me look for and find better ways to implement solutions over the years. I know that not everything needs to be optimized, after all, sometimes we do more work in the physical world because of expediency, but we know the tradeoff. We can judge if it’s worth it.

    Too often I see people think the computer is doing the work and they dismiss the effort. It’s the same attitude people have in the real world when someone else has to move/lift/pay for something. It means less to them.

    Treat everything as if you had to do the work yourself. You’ll treat others better and appreciate the effort spent, whether it’s another human, a software program or an AI LLM. Your results will show better judgment, and hopefully, quality.

    Steve Jones

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

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

  • The Quiet Part

    Apparently, Meta did what a lot of employees suspect their management will do: use AI to lay off people. In this case, there is a report (and lawsuit) that Meta used it’s AI-integrated HR platform to make decisions about who to let go in a layoff. The rumor is that the AI used productivity metrics to choose who was the target of the layoff. As with a lot of AI failures, this appears to be another case of poor communication guiding the AI, or the AI not actually taking individual situations into account.

    A number of the people terminated were on maternity/paternity leave, which is a protected activity. Others may have been on other medical leave, though for privacy reasons, the article doesn’t have firm data to prove this. The lawsuit will likely bring more of this out, but this appears to be a case not just of AI making decisions, but of poor behavior from management. Plaintiffs were discouraged from taking leave off, which is something sh****y humans have said to people for decades. We need you; your baby or family isn’t important, so don’t use your leave. It’s one aspect of working in the US that is way worse than overseas, where there are more employee protections.

    Meta disputes the case, saying the AI didn’t make decisions. However, that brings out an interesting point. If the AI recommends things, who’s responsible? The humans, right? They still have to sign off on the decision. If they don’t perform due diligence, they’re still responsible, correct? I think so; after all, I’m responsible for code the AI writes if I commit it. Even if an agent does the work, I have to oversee it and approve (or grant permissions for) the actions.

    I. Am. Responsible.

    Trusting an AI to do a lot of work is like trusting a lot of smart, but very inexperienced staffers to work in your environment. There are always inconsistencies and reasons why we might code something, configure something, or deploy something a certain way. What seems like a good way to tackle the situation from the outside doesn’t always make sense when you have experience. Humans often have experience that AI agents lack.

    LLMs are relatively stateless, and while we can provide context, give them guidance, and provide comprehensive codebases, they still sometimes do silly things. This can be problematic, especially with database changes, which are stateful and disruptive to rollback.

    AI agents can make mistakes much like humans, only faster. Much, much faster.

    Labor is one of the most expensive parts of many organizations’ budgets. Plenty of management would like to replace relatively expensive humans with cheaper tokens. That isn’t working out as well in practice, despite lots of experiments. Hopefully, other organizations realize that AI is a tool, not a replacement for humans, and we can’t trust it or even believe it’s outputs without some human judgment.

    Steve Jones

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

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