Voice of the DBA

Category: Editorial

  • Done is Better than Good

    Mary Spender is a musician in the UK who I follow and hope to see live one day. She works hard producing content about music, that business, and, of course, songs. Recently she had a little essay on Instagram where talked about creative time and focus. In it she referenced Elizabeth Gilbert saying “done is better than good.”

    My initial reaction was “that’s right.”

    Then I thought about software, and poor queries impacting database performance, and thought, “No, that’s not right.” My next reaction was to think maybe it’s “done is better than great”. I do see plenty of engineers trying to build great software. Code that would impress their peers or their former professors. Or maybe their future self.

    Then I thought, no, Elizabeth is right. If things don’t get done, then what’s the point?

    At the same time, I think that “done” and “good” (or great) aren’t mutually exclusive. We can get things done and make them great, which is something to strive for. We can also get good things done.

    Sometimes.

    Sometimes we don’t have that luxury of time, for various reasons. If I had to make a trade, I push for good (or quality) as much as possible if the delay isn’t substantial. If it is, then done is likely the choice I’d make. I do try to return and refactor, improve, etc. to raise the quality over time, but I recognize that sometimes getting something done is important. Certainly, on the ranch, I need to fix things to get by, with the aim of doing a better job later. I have mixed success at returning to improve a patch with a better fix later, but so far, that’s worked well. I’d say the same thing has happened while building software or managing systems, with enough success to be comfortable with my choices.

    What about you? What choices have you had to make about being done over delivering something that’s good? Or maybe great.

    Steve Jones

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

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

  • Is Data Modeling Common?

    Recently, I had a few questions on database modeling. One was posted in the SQL Server Central forums, and a customer asked about ERD tooling on the same day. This came shortly after Redgate acquired Vertabelo (now Redgate Data Modeler). This stood out to me as very rarely in the last few years have I found people consulting and updating a diagram while performing database development.

    When I started as a developer and needed to update a database, I had to first update a diagram that was stored in ErWin. We had a dedicated computer (back when we went to an office every day) where the software was run and any developer could us this to update the diagram with proposed changes. Back then, we had to get another peer to sign off on changes before making them, and the peer was supposed to go check the diagram for the change before approving it. That’s only if they thought your change made sense and conformed to our standards (naming, design, etc.).

    Over the last decade or so, it seems there haven’t been a lot of common tools for building diagrams in the Microsoft space. The SSMS Database Diagrams haven’t been the easiest to use and I rarely see people consult it. I loved ER/Studio, but it and ErWin were very expensive and outside the budget for most groups. There have been a lot of smaller online tools, but I don’t see a lot of consensus for which ones people like. There are DbSchema and SqlDBM, among others. I see various blogs, like this one, that recommend different tools, but the uptake seems to be low in many organizations. I hope Redgate can make data modeling more common with Redgate Data Modeler (coming soon to the Toolbelt).

    My question for you is do you still maintain and use database diagrams for development? Or is this a somewhat lost art? Is it not necessary or useful for you? Do you wish your development teams did this to ensure a more cohesive and consistent model?

    I used to like having a diagram because it a) forced me to slow down and rethink things a bit as I made updates and b) let me see where there were dependencies. One of the reasons SQL Dependency Tracker exists is that I asked Redgate to extract the dependency tree from SQL Compare to allow me to see it separately. This would allow me to know what other objects might need to be changed if I refactored ObjectA. I found that to be a great “picklist” of things to check during database development.

    I don’t know how many people these days perform data modeling, but I do know a lot who don’t spend much time thinking about the changes they make. I fear data modeling has become a bit of a lost art, which saddens me.

    Steve Jones

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

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

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