Voice of the DBA

Category: Editorial

  • AI Steals Joy

    Take a moment and think about how much work you do each day. If you write code, how much time do you actually spend writing code around meetings, admin work, and other tasks. If you manage systems and develop scripts, how often do you get to work on a script, change it, upgrade it, or add a new feature? I bet it’s a minority of time for most of you. Studies show that many developers spend only an hour or two writing code each day. I would guess it’s lower for sysadmins or DBAs who incorporate coding into their jobs.

    Now think about how much you enjoy each thing you do. I assume meetings aren’t the most exciting thing you work on, nor is updating a document for others to read. When I wrote code as the main part of my job, solving the problem, trying different algorithms, experimenting with enhancements, those were the fun times.

    Now imagine having a competent AI assistant that works with you. What if the AI does the coding and leaves you with the meetings and writing of specifications? It could happen. While it might be fun to direct a team of agents, you still need to understand software architecture and development, but you might not want to get away from writing code.

    As more developers start to use AI agents to get work done, there is rising dissatisfaction among developers because the AI can do quite a bit of the coding, which is the thing that most developers love. The AI doesn’t help with any of the other busy work, though AI agents might do a better job of ensuring docs match committed code (or released code).

    What I’d really like is an AI that would take my place at meetings. Maybe do a report for me or take a summary back, get some action items for me. An AI agent could handle things that wouldn’t necessarily be fun for me. Not all tedious things, but it could free up more time for coding.

    However, that’s not what the GenAI agents are being positioned to do. They’re stealing the joyous part of development. At least, if managers have their way, that’s the place they’ll use GenAI most.

    Steve Jones

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

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

  • The Security of Old Tech

    There has been a lot of news about air traffic problems in the US in 2025. I haven’t had any delays due to this, though I’ve gotten a few messages in my travels that I might want to reschedule. There was an article that some of the technology still used in various facilities is old and needs upgrading. Old as in Windows 95 and floppy disks.

    That’s old, but obviously it still works. Even with the various accounts of problems, almost every day thousands of flights are managed successfully by the people who run these systems. They’re not alone, as the article also points out that some other transit systems make do with technology that most of us would never think of using for any system.

    In early 2024, Microsoft was attacked by Midnight Blizzard, a nation-state threat actor that successfully infiltrated a test system and gained access to many other systems inside the Microsoft network. The initial attack was via a password spray attack (guessing multiple passwords), targeting an admin account on a test system that lacked MFA and robust monitoring.

    The trouble with air traffic controllers and the Microsoft attack are two disparate events, but they both highlight that there is a lot of older technology in use, even in places like Microsoft, a supposedly cutting-edge company. I’m sure many of you have some older systems inside your organization, hopefully not running Windows 95 or SQL Server 2000, but I routinely run into SQL Server 2008 inside customers.

    There have been a lot of changes since the year 2000 with regards to security inside of computer systems. Many software packages have upgraded their security features and configuration in the last 20-plus years to become more robust. These days it seems that most of the software I use requires some sort of authentication besides a password, with lockouts and limits to prevent hackers from easily accessing systems.

    This isn’t to say that newer technology is fool-proof, but it is more difficult for most hackers, especially the script-kiddies who copy exploit code from others, to break in. A lot of attacks can be prevented by simple changes that limit the ability of malicious users from experimenting over and over with your systems, looking for vulnerabilities.

    However, quite a few of those security changes require newer versions. Older technology often works and works well. We feel comfortable with it, and if it’s not broken, why fix (or change) it?

    I expect a database server to run for 10 years, as it can be hard to find time to constantly upgrade instances. That being said, a ten year old system would be one running SQL Server 2016. Anything older should already be upgraded, with plans to move your 2016 servers to something newer in the next year.

    Take advantage of newer technology where you can, and ensure you are patched against known vulnerabilities. If you can’t upgrade, then you should secure those systems as tightly as you can, ensure no accounts on them are privileged on other systems, and monitor them constantly for potential issues. Otherwise, I’m not sure you’re doing a professional job of managing those servers.

    Steve Jones

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

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

  • Password Guidance

    I remember working at a large organization with a team of other IT Operations staffers. We rotated this one job every month amongst a few people, each taking turns, where we’d lose a day to update all the privileged passwords for our servers. This was before Managed Service Accounts and the cloud, when we were required to change these every 30 days and then store the new ones in an encrypted store.

    What struck me when I got stuck with this wasn’t the requirement to change every 30 days; that seemed normal. The thing that bothered me was how manual this was. As a former developer, I wrote some scripts to automated this, pre-PowerShell, and make the task easier on my fellow sys admins. I had scripts to generate a password, change it in AD, then print the pwd to be copied into our secure storage (no API there). This ran in a loop so I didn’t lose a whole day to changing password.

    These days, we have lots of alternatives to managing passwords, and in fact, much of modern guidance isn’t to require password changes so often. For systems, use an automated process such as an MSA or GMSA. For users, we’ve mostly given up on changes and are trying to get people to use decently long passwords and disparate ones across services.

    Modern guidance from Microsoft says to avoid using common passwords (asdfasdf, password1, ec.) and don’t use the same password in multiple places. MFA is also recommended, but the anti-patterns for success are requiring long, complex passwords or frequent changes. Studies show these lead to less security because users do stupid things.

    These days, I would guess many of you managing database systems use some sort of integrated security with AD, Entra, OAuth, etc. However, I know there are still places where passwords are in use. Do you require changes often? Do you change any of your passwords regularly?

    Security is always hard, and it’s even harder when the recommendations and rules aren’t consistent or even enforced. I don’t know what to do, but I try to use disparate, long passwords and MFA wherever I can. So far that’s worked well.

    Steve Jones

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

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

  • Requiring Technical Debt Payments

    I was working with a customer recently that is trying to improve their processes. This was a large company, over 100,000 employees, though most of them aren’t in the technology area. However, across many divisions and groups, there are a lot of developers and operations personnel who have tended to work in silos, managing their own applications and systems in disparate ways.

    In other words, doing software development the way most companies do it.

    I had been working with one group to streamline and standardize some of their software practices to implement more of a DevOps flow to smoothly build, operate, and update their systems. They’ve had some success and other groups noticed that this set of teams is very efficient. They aren’t DevOps like a lot of the articles you read. They still have development and operations, but the groups work closely to ensure efficiency.

    They started to get requests to onboard other teams into their flow as the management of this group has been advertising their success. Other groups want to implement Continuous Integration, get database unit testing and static code analysis setup, implement gates for approval, and more. The Operations team manages most of this and is happy to help other groups.

    But

    They require some things to be in place, some of which are cleaning up technical debt. Not all debt, but certain things that create additional risk or instability. Before they onboard anyone, they don’t want to take on a codebase that is difficult to manage. A lot of this debt isn’t difficult, but they want some good coding practices implemented. They require integrated security or a waiver from InfoSec. They want explicit index names, not system-generated ones. They want permissions granted to roles, not users. Not big things, but little items that make a system less maintainable and understandable.

    The same things a lot of us let creep into our codebase over time.

    On one hand, I thought this was an idea that would slow adoption and allow many groups to continue to operate inefficiently. They won’t clean up code. On the other hand, this might be the lever that helps create a better run environment across the organization. This might help them smooth their upgrade cycles, let staff change between projects, and more importantly, reduce the overhead of communication and work between teams.

    I don’t know how this will work over time, but I am interested to see what happens.

    Steve Jones

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

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