Voice of the DBA

Category: Editorial

  • An Unexciting Exciting Release

    SQL Server 2025 was released this week. The announcement came at Ignite and the PASS Data Community Summit with keynotes on Wednesday and Thursday, respectively. While there are some things to look forward to in the release (What’s New) and some highlights from T-SQL Tuesday this week, it seems that this release wasn’t a very exciting one.

    On one hand, I blame all the Microsoft Fabric focus, which seems to distract from the core product that powers the databases at many organizations.  The SQL Server blog from Microsoft has had relatively few posts this year, highlighting a few things. The Fabric blog gets more posts, which is something I’ve seen at Database Weekly as well. As I curate the content during my week, I find a lot more Fabric-focused content than SQL Server-specific posts. That contributes to a lack of excitement for a new version of SQL Server.

    On the other hand, SQL Server is a very mature product and most of us use it daily, depend on it, and feel comfortable with the way it works. While some of us want changes, bugs fixed or features enhanced, for the most part, I find many clients expect it to just work and don’t have time to refactor code to use new features. A few also are nervous about using features until they’ve been in a few versions, as we sometimes see features released with limited functionality and few enhancements (*cough* these tables *cough* or these ones).

    At the same time, the What’s New page has a lot of stuff listed. If not more than SQL Server 2022 and 2019, it’s in more categories. Maybe it’s just that the documentation writers are more verbose? Perhaps, but I see lots of things I hadn’t noticed before in announcements. RegEx and the AI capabilities have dominated a lot of the news/blogs/etc., but the Change event streaming, native support for parquet/Delta, AG control flow, backup on secondaries, ADR for tempdb, and more are there. Plus, quite a few security enhancements to let us work with managed identities.

    When I really look at the product, there are things to be excited about, probably at least a couple for most people. At the same time, it has seemed like many people, including me, aren’t necessarily overly excited about upgrading systems to a new version when much of our code won’t change.

    Maybe because no one lets us, or gives us time to, change code to use new features.

    Steve Jones

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

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

  • Don’t Create Workslop

    I remember a time before email. Some of my first jobs were mostly based on paper being moved from person to person. I’m sure some of you remember these envelopes being used to communicate between individuals in an organization. I used those to send and get memorandums from others before we implemented email. Fortunately, our email implementation (cc:Mail) came soon after I started working in corporations.

    Initially, people treated email much like paper mail inside organizations. However, over time, people started to treat email differently. It was easy to send an email around other work, so people started to send more messages than they ever would have with paper. They started to dash off notes quickly, sometimes too quickly, as an email might be followed by another email that includes a “I forgot this”. As instant messaging grew, we saw similar patterns where people were quick to send messages, regardless of whether they were important, well-thought-out, or even necessary.

    As AI becomes more widely used in the workplace, there’s a similar tendency. People are quick to use AI to generate something and send it to others, often without due diligence on their part to ensure the work is at the quality level the other person expects. Some workers don’t double-check what they received from the GenAI tool, and it may not be complete enough to actually satisfy the requirements they were given. Maybe even worse, the result might not be targeted at the problem that was supposed to be solved.

    I ran across an article on workslop, which is defined as AI-generated work that masquerades as good work. Instead of actually being what the organization needs, it’s sloppy, it’s low quality, or it misses the mark.

    To be fair, I don’t think this is an AI issue. I have worked with plenty of people who produced low-quality output that wasn’t good enough for me to use. I’ve seen plenty of people not really try to produce quality results and do a poor job of completing the tasks they were assigned. With AI, they can do it quicker, which can be a problem, especially if they are producing things other employees depend on or need. The result might be some people be pushing their work onto others who have to spend time fixing (or completing) the copy/pasted GenAI results, taking away from the time others might spend on more important tasks.

    In the technical world, we saw that in the 90s with VB6, where lots of technical and nontechnical people produced code quickly for an application that worked initially, but didn’t perform well, couldn’t be scaled to others, and wasn’t stable enough to run every day. Sometimes not stable enough for an hour. I suspect we’ll see a lot of AI-generated code that repeats this pattern. Not because the AI can’t generate good code, but the people using it won’t know how to ask for good code, with instructions about the types of code that create robust applications. They also won’t know (or won’t bother) to check the code for quality.

    My guess is that the GenAI adaptation to lots of work will result in a lot of things produced, but at a lower quality than we might want. We’ll also see this phenomenon create inefficiencies as other workers have to return or repeat work. Fortunately, there is a lot of room for inefficiency in many organizations, so they can likely continue to function.

    Those that learn to use GenAI well to produce higher quality work will do so faster and stand out from their peers. Of course, a big part of standing out is also developing strong soft skills and advocating for your accomplishments. Without that, you might find those who produce workslop, but talk about it well to others will stand out from you.

    Steve Jones

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

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

  • Being Mindful of Design Time

    Over the last few years, I’ve worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code.

    In many cases, however, what lots of management wants is speed, and they’re looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone’s goals.

    However.

    What I see too often is that both their current process and the new one are often lacking fundamental database design and modeling. Developers aren’t well-trained and make design decisions based on an (often) incomplete spec. They alter schemas to fit the immediate challenge, without thinking about the future. Good database modeling considers the often unasked questions and unspoken rules of the problem space.

    Moving to a smoother process that allows code to be merged, tested, and released in a quicker fashion is great if you are writing good code. It’s less great if you aren’t. Most of us have a lot of poorly architected schemas and don’t need more challenges from more bad designs or bad code.

    I wonder how much time most of you spend on database modeling? Do you try to out more than one design? In this podcast, John Ousterhout talks about designing a system twice. He tries to get his students to come up with a second idea for a problem, which often brings out a better design. I wonder if this might not be a good idea for database modeling as well.

    I’m sure most people do their best to build a good data model, but experience often teaches us that the way we decide on a table structure, data types, keys, indexes, and more changes as we learn more. Our experience can help us make choices that perform well over time and don’t limit flexibility.

    Is design an important part of your development process? Do you have guidelines for your organization? Do you consult more experienced database people? Or to inexperienced people ask you to review their choices? Building a more efficient software development process should help you to move code to production more smoothly, and therefore quicker, but it shouldn’t be used to deploy more poorly written solutions. Take the time needed to implement well-designed and tested code, including your database code.

    Steve Jones

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

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

  • Internal Staff Growth

    Imagine that you are about to tackle a new project that will take more than a year. This might be a new system, perhaps a cloud migration, or maybe it’s rewriting something that doesn’t work well. You don’t have enough employees to undertake the project without overloading everyone. Your team needs to grow.

    Would you rather hire a more senior person from outside the organization or pick a junior person that’s already inside your company and teach them what they need to know? Think about this as if you were the one making the decision about the future direction of your software team. Philosophically, do you want to buy experienced people or train/build new ones from your internal staff.

    It’s an interesting idea and for a lot of companies, I see them looking outside the company first, rather than investing in, and training, their internal staffers to grow. It takes time to train and grow people, for sure, and it’s a constant investment that never goes away. At the same time, bringing people in from the outside also requires some level of training on how the current systems and org work, even if the new hire has a lot of experience.

    I think there are good reasons to look at both of these, but my view is that I want to have people on a team that know how to work together. The tech skills (or design, modeling, etc.) can be taught, and I would rather have a good cultural fit, already knowing how a person fits with others. That assumes I’ve got good employees who fit together and believe in our culture. That’s hard enough to do, which is why I want to hire people who can work as a team and keep them. Part of the “keeping” them is investing in them.

    This also means that if people don’t fit in, I want to help them move on to a better fit.

    This doesn’t mean I want everyone to think the same. It is important to have a variety of views on how to design and build applications. A variety of people is important, but we have to be a team.

    I prefer to train and invest in the people I have over bringing in more experienced staffers. A big part of why I feel this way is that hiring is always a gamble, and it seems we make no shortage of mistakes. If I do get it right, then I want to grow and keep those people around for the long term.

    Steve Jones

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

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