Category: Editorial

  • Republish: Upgrading Your OS

    Two Fridays in a row. Last week I was in Dallas at a volleyball tournament. Today I’m flying all day, returning from the UK. It’s the Easter holiday there, and some of you might be taking off today as well.

    Hopefully it’s a smooth journey for me, but you get to re-read Upgrading Your OS, which is an interesting one for me to look back on. I’m still on W10 on my desktop, but Microsoft is again pushing an upgrade, this time to Windows 11.

    I didn’t love the upgrade on my previous laptop, but the new one I got late last year seems OK. Some weird things with W11 have me hesitating to upgrade the desktop, but I’m torn. I certainly don’t want to get away from security updates.

    How do you feel? Leave a comment in the editorial.

  • Database First or Application First

    One of the challenges in software development is coordinating database and application changes when one depends on the other. I find many software development teams struggle with this, especially in today’s environments when no one wants to take a system offline. While some companies can stage and manage deployments, many of us find our systems need to keep running 24×7 with minimal outages (if any).

    Lots of you work in environments where your software is changing on a regular basis. Plenty of you will either be developing those changes, or managing the systems to which those changes are deployed. You likely will be coordinating with other people (in either case) to deploy a software artifact (C#, Java, Python, etc.) and a set of database changes in order for your clients to use whatever new functionality is being delivered.

    My question today is do you deploy database changes first or application changes first. Certainly you can deploy both on the same day or in the same pipeline. However, even if you use parallel pipelines, likely one side will finish first, and you likely have some preferred order for deployments. My question today is what order do you prefer (or is mandated to you).

    Maybe you don’t care. After all, with modern coding and feature flags, you can deploy either side first (front end or back end) and not disturb your clients. I’ve seen many successful deployments from organizations both ways. Some like letting application developers deploy their code with expected database changes hidden behind flags. Others want the database to get patched and the software changed later to use the database changes.

    Lots of people want everything deployed at once, but if you assume that is the case, I hope you have downtime scheduled, as you can’t usually get everything deployed simultaneously.

    I tend to prefer database first, with dark deployed changes that don’t affect the front end. Of course the front end needs to support these dark deployed changes, but that’s easy by just following good coding practices, which aren’t that hard.

    Let me know today what you prefer and why. Or if you don’t care and can deploy in either order.

    Steve Jones

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

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

  • How Much AI Code Would You Use?

    I saw an article recently that a quarter of the Y Combinator startups have 95% of the code in their repos being AI generated. The article notes that if no other startups had any AI generated code (no idea the likelihood here, then about 24% of their code for startups is GenAI written.

    24%

    Is that high or low? If you think about all the code you’ve written in the last year, how much of it could be reasonably generated by AI? All the queries, schema changes, test code, dummy data insertions, refactoring to add a column to a table or result set. Could it be AI written?

    Let’s assume you practice a bit and you could quickly get some table, view, and sproc code. If I were to ask an AI to add a date column to a table and adjust the view and sproc code, is that useful? If I can move on to another task, or start setting up a prompt to add some test queries (or tsqlt tests) for me, that might make me more efficient. Certainly I’d still have to think of how to model this, but could the AI save time?

    There is a lot of code that AIs might not write well. Certainly any dynamic SQL stuff that might be susceptible to SQL Injection worries me. An AI might write this, but so can a human. If the human doesn’t understand this issue, then it doesn’t matter if the AI writes it or the human does.

    Except the human can make more mistakes in a period of time with an AI helper than by themselves. At least, I think they will unless they just can copy/paste/search/replace the code themselves. Then maybe they can do the same level of damage to a codebase.

    The article has this great quote: “… even if product builders rely heavily on AI, one skill they would have to be good at is reading the code and finding bugs.” That is very true, and it needs to be said to every manager, project leader, and executive. You still need trained, skilled, experienced developers.

    This might be even more true for DBAs and ops people using AI to help them write scripts to change infrastructure. Plenty of people do this poorly now, but how many more quick scripts written by an AI will include unintended, insecure, or otherwise problematic code? People need to use the AI as a tool and review the output before using it.

    So how much help could you get from an AI in your coding? 24%? 95% Let us know today.

    Steve Jones

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

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

  • Part-Time DBAs

    Some of you reading this are database administrators (DBAs) who manage systems as their full-time job. Others of you might be developers, analytics people, or someone else who has another job, but you get stuck with managing the database somehow. I’ve seen a receptionist and a dental hygienist act in this role. We may call you the accidental DBAs, though that doesn’t imply you are good or bad at managing databases. I got into this line of work as an accidental DBA who was also a developer.

    No matter what your job title, my guess is that you aren’t over-staffed at your organization. Likely you wish you had one (or more) more person to help keep up with the work. It seems that we never have enough time to get everything done in a week. And that’s with a full staff. What do you do when someone is sick or goes on vacation? If you’re like me, you get further behind and feel extra stress while your coworker is out of the office.

    There is another way, and I thought this piece had a great title: Having a Part-time Database Administrator Can Help Improve your Bottom Line. It’s from DCAC, a consulting company that provides remote DBA services. There are other companies like this, such as Procure SQL, Straight Path Solutions, Dallas DBAs, and more. All of these companies are available to help augment or relieve pressure on your staff.

    The piece makes a good argument that often your staff is busy and might not have some of the specialized training or advanced skills that might help solve complex performance issues, architect HA solutions, perform cloud migrations, and more. For many companies, it can be hard to acquire these types of skills, and even if you have a plan, it can be expensive. What if your expert is out of town when you need them. What if you train them and they leave? I believe in training people, but I also know that you have to be able to augment your staff at times.

    Using trusted partners to help you improve parts of your business is something companies do in many ways. We might employ a handyman, but would still hire an outside plumber for some work, especially if it is a large job. Why not do the same thing with your technical staff?

    These companies might seem expensive when you look at their rates, but using them part-time, in strategic places, can often help your bottom line.

    Steve Jones

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

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