Voice of the DBA

Category: Editorial

  • Who is Irresponsible?

    There was a post on X recently from a founder in the EU about an engineer using Claude and ChatGPT to build a feature. I am not sure how true these posts are or if they are designed to just create engagement, but it’s still an interesting topic. The part that makes me think is that (supposedly) the engineer was fired because their “data” (code) was sent to American servers. The code was then deleted and the feature will be built without AI.

    First, read some of the responses before you form an opinion. There are some funny ones in there. There are a few I think are overblown and silly, and I skim past them. Someone is always more upset than I am, and more than I think they rationally should be, so I tend to let their outrage flow by me.

    There are two interesting things here. First, the debate about sending data to America. There certainly is some cause for concern here if data is being sent to a place outside of the EU where GDPR rules might apply. There possibly could be some legal issue here, though I doubt some of the responses about all code being compromised are an issue here. I don’t think code is PII, though if it were re-used or appears in AI output, perhaps investors could sue this company.

    The second thing here is whether someone should be fired for doing this. There might be a policy and some training about not doing this, and in that case, perhaps the person should be fired. However, I find this kind of thing happening too often, and it’s the type of thing that has happened before AI where people used outside sources (SQL Server Central, Stack Overflow, etc.) to post code in a question and get an answer. And then often use that code without changing or testing it.

    Is this rational? Some people might say yes, some no, many unsure. In the past, before AI, what would you think? To me, sometimes there have been solutions engineers have found but couldn’t use code written by someone else. There are real IP/copyright concerns here. You could rebuild the solution, rewriting the code, which in some sense is what Google did with Java APIs and successfully defended that effort. If another human or an AI gives you code, can you rewrite that code, keeping the same idea for the solution?

    I think that in most cases this is acceptable. I use AI for a lot of things and I throw away a lot of AI output, but it often gets me started down a path, whether in writing, coding, or something else.

    Who was more irresponsible here, the founder or the engineer? I think the former.

    Steve Jones

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

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

  • Poor Names

    It’s always interesting to me when I give product feedback to engineers at Redgate on their demos. Quite often they’ve built a feature that uses AdventureWorks or Pagila (PostgreSQL) or some other well known schema to evaluate how their particular thing works with a database. I try to remind them that many databases aren’t well modeled and designed with consistent naming.

    I ran across a Daily WTF article that isn’t showcasing databases, but it does show some poor naming in data being stored in a PDF. The developer who had to automate a process had to map these fields to database fields, which also might not be named very clearly. In fact, I think I’ve seen a few database models that used column names like the field names in the PDF.

    Most systems we work on evolve over time. They aren’t built by one programmer, or one team, across any period of time. Existing developers leave and new ones start. DBAs change, and we often don’t have any code analysis rules enabled or running in CI that might help us with consistency.  Often we don’t even have our rules documented.

    Humans are amazingly creative beings, but they also get very uncreative when they have to repeat that creativity over and over. It’s why we find a neighborhoods in Colorado with Pine St, Pine Ln, Pine Rd, Pine Circle, Pine Way, etc. You get the idea. Someone got bored and didn’t want to be creative, so they just took the easy way out.

    The same thing happens in databases. I’ve seen people have a Customer table and then a CustomerDetails table alongside it (singular and plural) with a custDefault (case) and a tblCustContact (prefix) table that leave me scratching my head. Did the next developer not look at the database at all? Certainly they didn’t use any modeling tool like Redgate Data Modeler.

    I don’t blame others, since I’ve found myself struggling to be creative as well as consistent when I build systems. Sometimes I’ve got some automation running that reminds me to do better, but often I’m depending on another human to catch these inconsistencies in a code review. However, I’m not sure code reviews include looking at the name of the object for most people. Well, maybe column names, but that might be it.

    I’d hope an AI system could recognize poor names and then suggest better ones that capture the intent of the data being stored and look like the other objects in the database. Unfortunately, that will likely lead to a section in the database that looks amazing while all the older objects drive you crazy with their random nature. Maybe the AI can at least update the comment or description fields in code to ensure there’s some place to look for information to help us do better in the future.

    Steve Jones

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

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

  • Acting with Confidence

    Recently, I saw a graph about making decisions that showed the impact of both reversibility and consequences. Here is an example of such a graph and how one might approach decisions. If things are easily reversible or have a low consequence, we tend to make a decision and move on. Or we are willing to make a decision. One of the examples of such a decision was choosing what to wear out to dinner. It’s easy to change, and (in general) of little consequence. Choosing to send a large amount of money to someone through Venmo (or some other mechanism), can be hard to reverse and have substantial consequences.

    This made me think of some of the DBA and developer decisions I’ve made in the past. When we work with databases, the changes we make can have a large impact and be quite consequential to our organization. Downtime, data quality, etc. could all impact revenue, profit, reputation, or even future prospects of survival. That can be a lot of pressure when you are deciding to refactor a data model or adjust a lot of data during a deployment.

    We might think we can rollback or undo changes, but often we would end up applying reversing transactions. If I change a data type, the data is changed ( assuming the DML completes). To change back, I can’t roll back outside of a restore. I would change the type back and have an equally large and long transaction run. Having HA or replication technologies in the mix can dramatically impact the scope of both the initial and reversing transactions.

    How confident must you be in your actions before you undertake something of consequence? Do you require an easy rollback, or are you willing to act even if the rollback is painful?

    Maybe a better question is how do you appraise the consequence of an action? Is it the application/database or perhaps the data? You might consider all the dependencies from other applications or pipelines on this. I know many DBAs worry about the performance impact of changes that can slow or stop other work. I constantly see people asking if Flyway can estimate how long a change will take, especially when dev/test environments are a poor representation of production sizes, scales, and workloads.

    If you have a 2GB database, you might just make changes. A restore is quick, and I’ve often found greenfield applications taking this approach since the data sizes are small and even consequential actions can be undone with a restore operation. Many of the “code-first” technologies work great in these situations, but once we have multiple application dependencies and large data sets, restores can be non-trivial or even unacceptable ways to deal with issues.

    The image linked above talks about gathering data and analyzing, which sounds like the prudent thing to do, but this can be easier to say than do in practice. Deciding what analysis to undertake and how long to spend on it are the real tricks. Those are the judgment calls that only experienced humans can make. While AI might help, this is an area I really want capable humans with the final say.

    Steve Jones

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

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

  • Barely Reviewed Code

    Years ago I was giving a talk on software development and asked the audience how long it takes to review a PR that has 10 lines changed. Answers were in the minutes to tens of minutes range. I then asked how long it takes to review a PR that has 1,000 lines changed. Some people said hours, but a few people said seconds.

    I’ve often taken the latter, pessimistic view. Not because I don’t think engineers want to do a good job, but because I know human behavior. Most humans will get bored, lose focus, and end up skimming through a large amount of code. Many (most?) people don’t want to spend all that time, after all they have they their own code to write. They’ll just approve the PR and assume testing will catch any major issues.

    Even if a reviewer wants to do a great job, they likely will still miss things. It’s very hard to focus across that much code.

    This is a funny visual (from X) about code reviews. It’s titled “me reviewing code written by Claude before pushing it to production.” Plenty of people are probably laughing, or thinking this is a good reason to not use an AI to write code.

    However, I don’t think the problem is an AI writing code. If you trust the AI without reviewing things, that’s on you. You deserve blame if things fall apart.

    The bigger problem is that an AI can write code so quickly and can make so many changes that PRs will tend to be large. These changes will tend to not get human-reviewed with any level of focus or quality control. The problem is volume, not who wrote the code (or the quality). Certainly quality matters, but it’s easy to catch changes if you have a small volume of code. Harder if you have a lot.

    The more I use AI for spot work, to handle tedious things, to do something like subtly adjust spacing in a UI or focus on adjusting a few things in a data model, the easier it is to judge the focus and quality of the code. Is the change doing the job I need done, and is it doing it well?

    Code quality is a problem we’ve had ever since we started writing code. AI can make the problem worse, not because of poor coding, but because it will write so much code in a PR that you can’t review it appropriately.

    Steve Jones

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

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