Voice of the DBA

Category: Editorial

  • A Paste Policy

    Most of the code I’ve written for various employers was something that lived inside the organization. This was for internal use and no one outside of the organization ever used it. It was almost always code I’d written, so I wasn’t ever worried about the provenance of the code (where it came from).

    However, I’m sure I’ve copied code from somewhere online and used that in some way. I might have taken this function from Jeff Moden and dropped it on a production server where it was used to process a string. I’m sure I’ve taken code from various places and used it in administrative functions, like Ginger’s code to manage a log file.

    I don’t know that any of those authors would have minded using their code. After all, that’s why many of us have written articles and published things at SQL Server Central. We are looking to help others grow their knowledge, as well as provide them short solutions they can incorporate into their own work. I assume most of the people answering questions at SQL Server Central or Stack Overflow feel the same way. Use the code.

    In this new age of AI, perhaps that’s OK, or perhaps it’s not. There is concern about who owns code and who has rights. At Redgate, we build software that’s sold and installed on other machines, so we have stricter guidelines. Our policy (in general) is “You MUST NOT include source code of unknown provenance in your application.” I saw a note recently that said this also applies to any AI-generated code, even if we provide the prompts.

    I doubt many organizations have policies about using code from the Internet, but I wonder if they should. Possibly there might be ownership or usage issues with AI code. If someone posts code on SSC that’s one thing, but getting code from an AI that might have been trained (and regurgitates) code that is not freely posted could be a problem.

    Maybe it doesn’t matter. After all, in your corporate CRUD application or some DBA maintenance script, it’s unlikely anyone will be auditing the code for any sort of misuse or copyright infringement.

    Steve Jones

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

  • HIPPO vs. Data

    One trend for many organizations is to be data-driven. This means using data to make decisions at all levels, or at least support those decisions. This was popularized by many companies, and there is research to back up the claims that those organizations who do this have more success, more revenue, more profitability, etc. Much like DevOps, however, it seems many organizations don’t want to actually invest in making data-driven decisions.

    Instead, many opt to make decisions by HIPPO. If you’ve never seen this acronym, it stands for highest paid person’s opinion. Many managers will defer to whoever is above them in the org chart, often someone that is paid more money than them. Even when there is data to make a different decision, the HIPPO is still used.

    It’s not just management. I sometimes see technical people do this. In that case, it might be the loudest or most senior person rather than the highest paid, but the sentiment is the same. Rather than using a lot of information, someone makes a decision based on what they want/see/need/desire. I’ve seen this often with tooling, where one person likes Jenkins (or hates it), and the organization changes from  (or to) Octopus Deploy or Bamboo for no real reason. Lately, it seems some people are advocating moving from Azure DevOps to GitHub Actions because, well, I don’t know why. There’s not a good rational reason.

    The goal of collecting and using data is to do so intelligently and with purpose. And not just for big decisions, but for everyday actions. By senior managers and frontline people, to help guide a more efficient and effective company. This involves a lot of technical work, but also cultural change. We have to position data as a strategic and tactical asset that everyone shares and uses as the basis to make the entire organization better.

    Of course, these are similar to the concepts of DevOps. Let’s build software better. In practice, many attempts succeed initially but fail later as more and more groups fight individual incentives that promote one group’s goals over another’s. When silos aren’t broken down, we fall back into the same patterns.

    In this case, listening to (or lobbying) the HIPPO.

    Steve Jones

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

  • The Value of Doing Something

    I live on a working horse ranch. My wife boards, trains, and trims horses and has employees. Occasionally I have to help out with chores, or more often, fixing things. I was talking with a coworker recently and showing some pictures. He was asking why I do things like tap a bolt instead of hiring someone to do it.

    I caught this excerpt from a book on cooking, which got me thinking. I don’t love the flow here, as it wanders between cooking, economics, politics, social justice, and more. However, the core ideas of specialization and taking on a task was what I got out of the piece.

    I work for a software company, and certainly, I make much more doing that than I save by cooking a meal or fixing a bolt. I could hire someone at much less than my hourly rate to do the work. Except, I don’t get paid more for working more. Maybe if I do more sales and get a quota, but for now an extra hour of work hasn’t helped me.

    Then there’s the satisfaction of getting something done. I talk and write and move bits around all day; nothing that has a tangible result. It can be satisfying but in a very different way than cooking or physically finishing a task. I actually like getting my hands dirty and seeing the results of my work. Seeing a new fence go up, a tree come down, or a repaired bolt brings about pride. I feel good when my family appreciates a tasty recipe and everyone cleans their plates. It’s a nice challenge.

    At the same time, routine maintenance, like changing oil, sometimes feels like doing an expense report. Needs to be done, it helps me, but there’s nothing very exciting about it.

    In the era of specialization, or even the era of automation and AI tools, it might seem that we don’t need to learn or work on anything outside of our area of expertise. I think it’s important to practice, learn, and use a variety of different skills. Even if I don’t need to write PoSh often, it is helpful to sometimes tackle work that needs doing. Each bit of new knowledge brings new understanding and appreciation for the work others do.

    It also helps me gain confidence in my ability to learn and use new technologies should the requirement arise. This has also served me in past jobs where I can step in and help others or even tackle a job when they aren’t available. This is something that I find far too many people struggling with. Either because of a lack of confidence or not having enough general skills that help them troubleshoot, build, or even support the vastly changing environments in which we work.

    Doing something old, new, challenging, or easy is good for all of us. Try something new, while you also appreciate and use the skills you have. Believe in your ability to learn and prove it to yourself on a regular basis.

    Steve Jones

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

  • Bare Metal

    At the first job I had as a DBA, I had to build a new server. This was in the days of SQL Server 4.2, and I was combination DBA, sysadmin, and general help desk at a small company. With a software developer consultant, we ran some tests on various machines and then ordered a collection of parts from Compaq. Back in this time, they would only customer parts of the server. We unpacked our boxes with the server, extra drive bay, various SCSI drives, and extra RAM. We assembled and tested the machine and eventually put it into production.

    In the years since then, I got out of the hardware business and left that to others. For awhile I worked in organizations with IT staff dedicated to building machines, but at some point we stopped doing that. The growth of VMWare and other hypervisors changed the paradigm for most organizations. For more than a decade, all the servers I’ve connected to are virtual machines running on hardware that my employer or a cloud provider owns and manages as a node in a cluster.

    Early on there were concerns about the overhead of using hypervisors and virtual machines. When many early workloads moved to VMs, lots of organizations left database servers on bare metal to squeeze every bit of performance out of the system that was possible. Over the years, improvements in hypervisors as well as the software used to connect storage and networks together seem to have rendered those conversations obsolete.

    Or have they?

    Today I’m wondering if any of you still have servers on bare metal. Are there systems that you continue to install the OS and database server software directly on the hardware? Or are there systems where you still ensure that there is only one VM, the database server VM, on a hardware node?

    The cloud has changed a lot of these conversations, since everything is a VM. Even many local data centers will rent you a VM, something that wasn’t possible when we first moved SQL Server Central out of a friend’s basement into a co-location facility. Back then we owned our servers and I installed them in data center racks. I would like to think we’d have moved our site to the cloud in some way over time, though maybe not. Maybe I’d still be managing a couple servers in a room in Denver.

    Are any of your organizations still running legacy systems in the same way you would have in 1999? Let us know today.

    Steve Jones

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