Voice of the DBA

Tag: software development

  • Development Is Fun

    I was listening to The Pragmatic Engineer interview Casey Muratori about high-performance code, which I found really interesting. I’m actually considering going through his Performance Aware Programming series and (re)learning some assembly. I never thought I’d even consider doing that. I learned Assembly in high school and university, and I didn’t enjoy it.

    Casey is a game programmer, and there was a question in the interview about how he uses AI tools in his work. “We are not using them” was not the answer I expected. Perhaps even more interesting was the rest of the answer. Casey loves programming and wants to enjoy what he does. He writes the code because he wants to do the work. If he didn’t, he’d license some game engine or technology, not spend time getting an AI to do the work.

    It’s an interesting interview, but it made me wonder how many people out there enjoy their work. How many want to go to work and get things done? Certainly, people want to get paid, but I would hope a lot of you have a job you enjoy doing, and aren’t necessarily looking to get someone, or something, to do the work for you.

    And how many go primarily because they have bills and need the paycheck? Would you rather be doing something else if you didn’t need the money?

    I love solving problems with customers, testing technology, and puzzling over the approaches to take when confronted with a challenge. I enjoy going to work, and while the paycheck matters, I like doing the work. I have no interest in retiring from my current job, as it’s fun. It’s hard some days, but mostly it’s fun.

    Do you still enjoy writing code? Or configuring and tuning servers? Or whatever you do? Are you looking forward to the day when you don’t have to do this job anymore?

    I don’t expect many people to comment unless they enjoy their jobs, but if you do, let me know.

    Steve Jones

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

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

  • Designing for Teams

    Some years ago, I had to register for my medical benefits with Redgate. My employer had contracted with Anthem for health insurance, and I went to register myself. I found that not only could I not register myself, but there was already an account there with my tax number, and it was under my wife’s account. Many years ago, she had health insurance with Anthem through another employer. Anthem kept her record, which includes my tax ID. So today, in 2026, I have to log into my Anthem account with her ID to see my plan.

    That’s likely an older, legacy system, so we might understand that they didn’t expect two people to be primary account holders over time, right? Well, we also have a more modern tax software system to deal with. Let’s call the software “Chewit” to protect the reputation of the company. When we contracted with an accountant for services, they set up an account for me. However, my wife manages most of the money, so I asked them to add an account for her. Apparently, this “Chewit” business tax service only allows for one person in a household to have an account. This person has to manage the account, so now when my wife logs in with my account, I get a code, and I send it to her. If you think these are isolated, I have 3 or 4 other services that work like this, from well-known, global brands.

    The quality of data modeling and software development is depressing some days.

    A lot of what I see from customers at Redgate, often from people who want to use Flyway to smooth our their database change management, is that they have built similar solutions that often depend on A person (or A server or AN account) to work. Someone hasn’t modeled things well for teams. Even when we try to smooth out a flow, often I see the users don’t account for the complexities of teams working together. I think some of this is because a demo or a model often shows a happy path, and we all tend to think in that mindset of a simple flow. Managing parallel actions is hard, just like parallel programming is a thing many people struggle to do well. Well, they struggle to make the code work without race conditions.

    I see the same thing in T-SQL. So many people think in terms of singletons, working with a row of data. They don’t think in sets, or as Jeff Moden put it recently, about how to work with the entire column at once. Thinking that way is harder and requires a new mindset, but that’s why we get paid well. Or should be paid well. We solve the hard problems.

    The world is more connected, more complex, and more likely to require teamwork. Whether that’s between partners/spouses in a household or different groups of people in an organization. We should be designing and modeling for teams, not individuals, in everything from data storage and security to user settings and customizations.

    Steve Jones

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

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

  • Absolute and Relative References

    This week I caught a short tale of Reitse trying to migrate a Power BI report from one Tenant to another in Fabric. It’s something that I would consider a common practice, whether it’s from a dev tenant to a prod one, or from a consultant to a client workspace. Moving things around is what we do in the digital world, whether that’s schema structure, a report, a data export, or something else. This is common.

    And it should be simple, right? I’m not complaining about Fabric here, though it should be easier. I don’t know if this is a Fabric problem, per se, or maybe it’s a Power BI issue. After all, I should be able to decide and link things in a relative or an absolute manner.

    I’m going through this as we test some movement of the SQL Server Central infrastructure. There is a mix of relative and absolute pathing, which breaks the test system. This is similar to the issues I’ve seen when copying files and configuration inside a local machine. Should I really have d:\git\myrepo\flyway.toml, or should this be .\flyway.toml and assume the reference will be in the repo? There’s no easy answer, whether you’re using Flyway, Docker, or any software.

    This is a place where the user should think for a moment about the future and what makes sense. Every month I I attach a file from SharePoint to an email to my Finance group. Outlook always asks me if I want a copy or a reference. Often, for internal links I want a link, so that if I edit the file (or the recipient does), we edit the same file. However, in this case, this is a document of record, so I want to know what I sent, without edits. If I edit things, I want to resend it.

    Often we want relative references, especially in the Cloud and Internet places, where we might move resources around, and we don’t want breakage. This is common when moving from dev to test to prod, or from one server to another. However, at times, we want absolute references. On the flip side, I want a standard in my SQL Server instances that puts my data files and backup files in standard locations. Data on the d: and e: drives, backups on the z: drive was a standard we used in one place.

    I’m not advocating that you lean one way or the other, but think about the purpose of the item and the future possibilities. Sometimes an absolute reference makes sense, and sometimes a relative one works better. If in doubt, I’d pick the latter, but be sure that whatever software or system in which you work supports this.

    Steve Jones

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