Voice of the DBA

Category: Editorial

  • Testing is Becoming More Important

    Many of us know that testing our code is important. The adoption of unit testing by many software application developers as a normal course of business has dramatically improved the quality of applications. Mobile software, especially, has benefited from the requirement for most software to include, and constantly run, a suite of unit tests.

    For database software, I find relatively few organizations formally test their database code. A few people have adopted tSQLt or the Microsoft Unit Testing Framework, but most don’t bother. In fact, many queries that are embedded in application code, or built by ORMs, aren’t tested beyond a developer looking at the results from their own (limited set of) test data. That often doesn’t catch errors until someone in production runs their application against a larger set of data.

    What might be worse is that refactoring those queries might produce different results that aren’t tested against regressions.

    In this new age of AI-assisted coding, testing is becoming more important. Grant wrote an interesting post on LinkedIn that discusses your job changing in the age of AI. You need to have more testing that ensures you validate code that the AI produces, which is going to be more important as the amount of code grows. AI will produce lots more code, and potentially, lots more poor code. We will need to ensure that the generated code  has some validation that the results are what we expect.

    Unit tests help here, and while I know these can be tedious to write and maintain, this is a great use for AI assistance. Generating unit tests, with default data based on data in current tables, is something AI agents can do well. They can also use these to verify functionality as code is generated and refactored. Of course, humans still need to be in the loop as there are plenty of reports where AI Agents write tests that return success without actually testing code. This is something humans have done as well.

    You need to validate the tests, and ensure your AI uses those tests to validate its work. Those tests can also be used by humans if they write code.

    AI is an amazing tool, but like an intelligent, over-eager, junior developer, it needs clear communication and strong guidance.

    And a little review of its work.

    Steve Jones

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

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

  • Can You Let Go of Determinism

    Why do we reboot machines when something goes wrong?

    I’m sure all have done it, and I would guess quite a few of you have found situations where this seems to fix issues, but there isn’t an underlying root cause that you can pinpoint.  This is a fairly accepted way of dealing with issues, but have you thought about why this is a way to solve some problems?

    The main thing that a reboot does is return the system to a know starting state. It’s why quite a few people complain about some modern laptops and mobile devices because they avoid restarts and try to sleep/wake instead. Most software expects to work on a stateless machine, so restarts help find a known good state.

    Coincidentally, this is why databases are so hard for many people, especially software developers. Databases are state machines, which are inherently more complex than stateless ones. However, that’s not the thing I want to discuss.

    If you think about code you’ve written and problems solved, which datatypes cause the most headaches and challenges? Which types of data are most difficult to deal with? There might be a variety of answers, but one of the most common ones is datetime data. The main reason? It’s not deterministic in many cases when we deal with calculations in real time. This data ages poorly and it’s hard to even test. By the time we’ve restored data from production, invariably our test data is old. We can de-age it (make it newer), but still, testing this data based on what happened yesterday is often hard.

    This has been on my mind as another modern technology has similar characteristics. AI LLMs are often not deterministic. The same prompt might not produce the same response, and like SQL Server execution plans, even small changes in the input can affect the output.

    That can be maddening to many of us, as we often want a reproduction of a problem to solve it. I ask for this from clients, Microsoft asks for it when I send them an issue, and most software developers want to be able to reproduce a problem on their machines. Or they often struggle to fix a bug.

    In this new AI world, is determinism something most of us can hold loosely? It’s a good question as many of us struggle with AI when we don’t get the response we expect, or even a good response. Worse, we might get varying levels of quality code back from the same models. I have found that an experiment I conduct sometimes cannot be reproduced with any accuracy.

    And sometimes it works the exact same way the second and third times I conduct the experiment.

    Humans are not deterministic. Many of us know someone that is very reliable and can predict how they react most of the time. Most, however, isn’t a characteristic of determinism. I guess in that sense, humans are a state machine as well, one that is constantly evolving and different every day.

    I find that success with modern AI LLMs requires me to accept some level of determinism and flow with it. I need to not expect the results to be perfect, and either massage the way I express the problem or give up. I’ve written it before, but I think learning when to give up on an LLM and just do the work yourself is a key skill for technologists.

    Maybe for anyone using LLMs.

    So, as you think about the future, are you prepared for one without determinism?

    Steve Jones

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

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

  • Doing Good at SQL Server Central

    This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month.

    We did photoshoots at Redgate many years ago. We had a bunch of props, including some phrases written down. We could create our own, but my handwriting is atrocious (likely why I never became an architect), but I ended up with this one:

    Steve Jones caption "Doing Good"

    I couldn’t really explain why I picked “Doing Good”, but the more I thought about it over the years, it’s been a lot of what has driven my life forward, both here at SQL Server Central and in my personal life. I’ve been a Boy Scout and Girl Scout leader, have been and am a sports coach, and I have given up no shortage of time to help others with speaking efforts. I put time into the SQL Saturday charitable foundation, trying to get more SQL Saturday and Day of Data events that teach, train, and inspire data professionals.

    SQL Server Central has a huge reach. We’ve been very popular, and millions of people have seen our newsletters. Our mission early on was to help database professionals get better every day, and we provided a lot of free (as in beer) resources: articles, quizzes, and answers to your questions. Many community members have also volunteered their time and expertise to help, and I thank them as well.

    There have been a few times when I’ve tried to use that reach to do good. I don’t want to point out the specifics, but a few times I’ve known people with very sick children. One was a local friend I’d worked with (tech pro, but not database) and another was a speaker in our community. This started when I was sitting at dinner with a fellow speaker, who was talking about this family struggling and needing help. I thought, surely we as a community could raise money and help them. I used the reach of our newsletter at that time to ask for donations and managed to raise substantial amounts of money to help a family. I did it again a few years later, raising well over USD$10k in both cases.

    In those cases, as well as with SQL Saturday, I have done what I thought was in the best interests of everyone and ensured all the monies raised went to the intended recipients. The families got all the money donated, and all sponsorship monies to to events. If there are bank charges or other fees, I absorb them. In the case of SQL Saturday, I go begging for donations to support the admin costs and fees.

    Those might be some of the things I’m most proud of in my life, which is an interesting thing I learned. I really like helping others. As much as I enjoy living my life, I get more satisfaction that I would have expected by helping others grow, learn, succeed, and enjoy their own lives.

    I think everyone should volunteer some of their time/resources/knowledge/etc. at some point in their life. It might not be now, but think about where you can help make the world better. You’ll gain way more than you ever spend from helping others..

    Steve Jones

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

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

  • Engineer Lessons

    Many of you reading this have a number of years working with technology. You might have 1 year or 20 years, but you’ve likely grown and learned along the way. Some of you may also know someone who has several years of seniority in a position but not that many years of experience. In this case, a person might have been working at this job for 5 years, but they really have one year of experience that’s been repeated 5 times.

    That’s been a common complaint over quite a few years from people who interview others. They find candidates often have very limited experience, yet are applying for senior roles. These candidates are ones who have just a few years of experience, but have ended up repeating those few years over and over.

    I ran across an interesting piece that contains 21 lessons from the author’s 14 years at Google. You might not think Google is the place where great software engineering takes place, or where great careers are made, but Google has been a place where it is challenging to get a job, they work on truly large-scale problems, and Google has had many engineers who have gone on to success elsewhere.

    The first few lessons in here are things that I’ve learned in my career. Quite a few of them point to the value of being a team player, and remembering that being effective and efficient matter. It’s easy to be smart, or depend on one’s code to speak for our ability, but in many cases, we are working in teams. Our code is a team game, and others need to understand our code. It’s easy to forget that someone responding to a problem at 2 am might not understand the code. It’s also easy to forget that person might be you, and you might get confused.

    Others also need to understand and believe in us. Lessons 2, 14, and 16 talk about the value of working with others and not creating resentment or ill will in others. Even with AI help, most software will require multiple people working together, so building those skills and habits is important.

    I found this to be an interesting list, and there are other topics I want to discuss in the future, but the main thing I see here is that these are lessons from someone who has had to work as a technical engineer with others, while having success both at his job and outside of it. That resonates with me, as do these lessons. Individuals and teams that work in similar ways to those described in the piece have tended to have more success than those that don’t, at least in my experience.

    Learn to be a team player as an engineer, developer. DBA, or any other job, and you will have more success than if you expect to only be judged on what code you write.

    Steve Jones

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

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