Voice of the DBA

Tag: software development

  • 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.

  • Are You Working More Hours?

    Recently, I noticed my son was coming home later and going to work earlier. He typically works a 9/80 schedule as a software engineer, but at times he might work extra hours on a deadline. His company tries hard to keep employees working a set schedule without overtime. Unless there is a need, after all, this is software. However, when they are on a deadline, management warns people, and they try to manage overtime to reasonable levels to avoid burning out employees.

    I asked him if he was extra busy or if AI was encouraging extra hours. He told me this was a short-term project with a few more hours, but mostly the team was decompressing a bit after work. I completely understood that as I’ve spent my share of time with co-workers at theend ofday, sometimes sharing a drink or meal nearby, sometimes just chatting in the office or the parking lot.

    There have been a number of studies and reports that AI is making people work more, not less. The time spent on a variety of tasks, especially those where we are reading or interacting with text, has grown. I suspect there is additional pressure from management as well to get more done since everyone has an AI assistant around. There is also the excitement of tackling new projects, which can lead people to spend more time at work. While I appreciate that AI can be exciting, and you might love it, don’t lose yourself in it at work. It’s still just a tool.

    And, of course, there’s the token spend. Some managers are measuring people on the amount of work their AI assistants do, rather than by what gets done. I’ve certainly seen plenty of people using AI to perform busy work just to be seen as using AI tools.

    At times, it seems people are using AI to process more information, which they then use AI to summarize. They post these summaries, which grow in number because the AI can produce more of them. Others use their AIs to read these summaries and produce their own summary of what they should be reading. It certainly seems like AI is producing more copies of information, summarized over and over, giving all of us more things to keep an eye on.

    That seems silly. While I like AI, I fall into that group that uses it lightly for targeted tasks. I certainly try not to create more reports, summaries, or even emails to send to others, especially large groups of people. We have enough to review without AI creating even more tasks to deal with every week.

    Steve Jones

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

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

  • Building Your Own Software

    Lots of AI usage has been spent inside companies on building new software. Sometimes people are trying to rebuild existing software. I’ve seen more than a few articles say that Slack is dead (it’s changing), or Monday is dead, or some other SaaS isn’t going to survive because people can vibe code their own replacement. I know a few people trying to do this, with very mixed success.

    I saw this post from Jason Friend of Basecamp, where he noted that most products wouldn’t exist if everyone were an entrepreneur. This is because the great products exist precisely because an entrepreneur had a great idea and followed it through. They made mistakes, they learned, and they spent a lot of time getting the product right. The coding was likely a part of this, but the mistakes, the changes of direction, the decisions on what to add or take away, those are time-consuming things not shortcut by AI. The coding isn’t the big delay in lots of products. A great response to the post notes this: there are many decisions that go into a product. Many people don’t think about all those decisions.

    Certainly, some people will use AI and do a great job coding a replacement for some existing product. They’ll make their own version of a product, likely learning a lot from existing software. They will shortcut some design and testing time since they know what they want. It’s the software they already use, and they know how it works. They don’t need to design it.

    However, the software is just part of the process, especially in the SaaS world. Infrastructure and operations are big. While a replacement Slack might not need quite the level of hardware, networking, DR, disks, etc., it needs a lot more than an individual can build and manage. An LLM might help you determine where your bottlenecks are and help you build the systems needed to manage more resources, but it’s going to take time. Especially if you don’t know what sorts of hardware and bottlenecks will occur as more people use your software.

    It’s also going to make mistakes.

    Imagine your LLM gives you a piece of bad code that doesn’t perform. We can refactor and fix that. Now imagine your LLM doesn’t configure DR correctly. Fixing that is a little harder, especially if you don’t realize DR is lacking until an incident occurs.

    Software is hard. One thing I’ve learned over the years in advocating for customers’ requests in Flyway, SQL Prompt, or Redgate Monitor is that the coding takes time and effort, but much less than the decisions on what and how to build something. Those eat up time and focus. Once you solve these, AI definitely helps the rest go quicker, especially if you have AI building tests. However, until you solve the problems around coding, it’s not necessarily faster or better.

    Steve Jones

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

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

  • The New Software Team

    One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

    In 2026, that hasn’t changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today’s world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

    In this short article on the rebirth of programming, the team is a team of n humans and m agents. N=1, and the architect, the coordinator, the project manager is the human (or a few humans). Code becomes less important, and the tests and other elements that describe and verify software become more important. Maybe even more important than today.

    I’d even go so far as to say the performance of the code might not matter in the short term. Since the cost of writing, or re-writing code, becomes lower and lower, when something doesn’t perform well, just spin off a new team of your agent coders who don’t need sleep, aren’t worse at development if they work more than 40 hours every week, and are always happy to tackle new work. It’s a project manager’s dream team. At least, in theory.

    That being said, the cost of writing this code isn’t zero. We see this rising every day, sometimes at a level that exceeds what we might pay human developers. That might change over time, but we certainly see some people spending more on tokens than salaries.

    And your agents do lose focus. Fortunately, you can fire them and hire new ones every day, or every hour. It’s like a team of characters in a game that respawn on demand to tackle the next challenge. There is still plenty of coordination and onboarding work for the manager. They will need excellent documentation and descriptions of what the code looks like, what needs to be done, and all of your guidelines on how to structure things. Lots of tests are needed, but your team can build them (with oversight).

    It seems like an amazing system, but we’re learning that excellent team leaders who are good architects are in short supply. And they can’t work long hours. Some early evaluation of these software managers seems to indicate that they can’t even work the full 8 hours for 5 days a week with a high level of effectiveness. They might not even be able to work half that amount of time.

    So is the falling cost of code going to produce more software? Likely, though perhaps with many more leaders needed to manage those teams. I can certainly see many more one person companies spawned during off hours, where one person can focus on their passion project, something completely separate from the work they are paid to do by someone else.

    It’s going to be fascinating to watch this work itself out across the next decade.

    Steve Jones

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

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