Voice of the DBA

Category: Editorial

  • Hidden Heroes

    A few weeks ago I was in Bletchley Park, at the facility where the Allies decoded and broke many of the German Nazi messages in World War II. It’s quite a facility and museum, and I hope to go back. I was distracted that day and didn’t get a lot of time to enjoy the exhibits and really learn more about what happened there.

    I was there for our Redgate 2026 Company Kickoff, and as a part of that, two different executives in our company shared their stories of people who had worked there. What was interesting is that until we planned this event, these two people had no idea that there were people they knew well, who had been part of the effort to end World War II at Bletchley Park. This facility can be considered to be one of the birthplaces of computing.

    They were some of the hidden heroes of World War II.

    Our executives drew a parallel of these people to our customers, notably the DBAs we work with. These are often hidden heroes in their organizations, toiling away, getting things done, keeping systems running, without the recognition or gratitude they might get if their efforts were more widely broadcast.

    That might be a bit of a stretch. However, many of us who work on database systems are doing essential work that our organizations depend on. If we do a poor job, many people complain. If we make mistakes, (usually) lives aren’t lost, but profits can be. Often, no one knows our names, we don’t get a lot of thanks for databases working well, and we have high expectations from our customers.

    Many of us know that data is critical for most organizations today. Many in management today are acknowledging this as well, at least to investors. I don’t know if they’ll ever start to truly appreciate data professionals with kudos and compensation. That might not be a step they’re willing to take since many other departments might claim to be just as important as they also work with data in some way.

    Perhaps we will remain the hidden heroes in today’s organizations.

    Steve Jones

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

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

  • Changing Data Types

    Recently I was working with a customer that is trying to smooth out their database development process. They noted that a lot of changes tend to take a significant amount of time and impact their availability. They came to Redgate to see if Flyway might be a way to improve the effectiveness of their internal groups that build, deploy, and manage their database software.

    We can help, but often when I get called to help architect things, we are trying to decide if the customer is a good fit for our solutions. Since we work on a subscription model, we want to be sure customers are happy and get value from their decision. Otherwise they have a poor experience and don’t renew. This might be because they aren’t ready, or it might be that the question wasn’t considered of whether our solution fits their environment well. In any case, I usually dig into the goals and challenges they’ve faced with their current process.

    In this case, they found that developers often changed data types of columns to better match the data being stored. That can be a disruptive change, and while Flyway does some amazing things, the software is still bound by the rules of making changes on the platform. In this case, SQL Server changes can sometimes be metadata-only changes, which are fast. Sometimes this isn’t the case.

    After the call, I started to wonder how often people change data types? I’ve rarely done this, and honestly, I’ve used a zero-downtime pattern a few times to add a new column, move data, use triggers, and then when I’m sure all data is moved, drop the old column. Changing types in place seems like a bad idea most of the time.

    Sometimes it’s not a big deal, but I prefer to avoid any potential problems if I can.

    That got me wondering. How often do you change data types in existing tables/columns? Is this because of poor data modeling? Changing requirements? Or are you lucky enough to avoid this?

    Or maybe you’re unlucky in that you can’t change those poorly chosen types.

    Steve Jones

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

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

  • Breaking Down Your Work

    I saw an interesting LinkedIn post on Kyler Murray and how he goes about approaching the game of American football. I don’t know if this meme is true, but certainly, his efforts to prepare have been a reported issue during Murray’s career. The post actually deals with sales and analyzing the reasons for deal success or failure, something I’ve been able to witness at Redgate the last few years. It’s interesting to me to see the sales process examined, though I don’t make sales.

    Incidentally, one of the comments is one I appreciate, referencing Kobe Bryant and the Mamba Mentality. I like the approach of working and asking questions to become better.

    Most of us technical people aren’t thinking of sales, but do we break down and re-examine how we do our jobs? Do we aim to improve the skills we have and develop more depth in the areas we work? I know lots of technical people like learning new skills, but is looking at the improvement (or refinement) of existing skills on your list?

    My experience has been that most people don’t look to grow deeper in many ways. They learn a thing and then often use that skill, but don’t often re-examine to see if they could actually do that thing in a new way. Technology changes, and it’s easy to think that the way you write SQL or build servers or implement security is good enough. It can pay to not only learn new things, but re-examine your existing patterns and practices to see if there are better ways to accomplish those tasks.

    This is where the one year of experience repeated ten times comes about with candidates who don’t interview well. They’ve been repeating patterns without improving them.

    I promote the idea of regularly improving your skills, sharpening your tools, and growing your abilities in a way that provides value for your employer and ensures you have a successful career.

    This is going to be more important in the future, especially with AI impacting the way many managers view technical work.

    Steve Jones

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

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

  • Multiple Deployment Processes

    We had a Simple Talks podcast recently where we discussed roll forward vs roll back. You can watch the episode and listen to our thoughts, but one interesting place was when we talked about deployments. Grant mentioned that he deployed from version control/source control at a previous employer. I asked him whether he did that for every system.

    His response: “Well, …”

    He admitted that most, but not all, databases came from a controlled source. There were some systems that had a more ad hoc change process. I wonder how many of you have consistent processes throughout your organization. I suspect not many of you do, especially if an organization isn’t small. Often, different groups and applications are in a constant state of flux, with lots of different processes and protocols.

    Some groups are more mature and have stable staff who expect to deploy changes in a certain way. This might be on a known cadence, with documents or processes in place already. Others applications might have been developed quickly; perhaps they are newer and use more automation to deploy changes. Some might even use things like packages from an ORM or a vendor that takes control of database changes away from anyone managing the database. Does anyone deal with Spring Boot and very optimistic developers?

    I wonder how many of you have a consistent process for promoting database code to production across all your teams. Maybe 80% is a better metric, as this accounts for those groups severely limited by legacy technology or those that might be experimenting with new ways of working.

    Even those companies that have platform engineering groups in place to ease the flow for both developers and operations often aren’t consistent throughout the organization. Often, getting everyone to adopt a standard is hard and takes time.

    That might be the biggest challenge with standardizing database deployments: time. Organizations grow and change, new technologies come, and by the time we think we’ve gotten everyone to agree to change, who everyone is has changed. We have someone or something new, and we’re forever chasing standardization. Even when we might have a great DevOps process or a platform engineering team for software, we don’t do this for databases.

    I believe having a consistent, standardized process is a worthwhile goal, but one where 80% success is probably good enough in most organizations. If you can get most teams to follow the same process, you’ll increase efficiencies and ensure a better software development life cycle.

    Steve Jones

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

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