Voice of the DBA

Category: Editorial

  • The Pressure to Perform

    I’ve worked as a technical person for most of career. I’ve often been responsible for building or managing systems, and ensuring they operated according to some set of requirements. If things didn’t work, I’d have to fix them, but often there wasn’t the threat of losing employment unless I was grossly incompetent. If I made a strong effort, I’d get other another chance, or maybe be shuffled to work on some other application or system.

    Throughout my career, I have worked with various salespeople in different companies. Either they were my customers/clients or they were just co-workers. However, they operated under a different mindset. Most salespeople are expected to make a certain amount of sales in a time period, and if they don’t, they may be let go. In fact, in quite a few companies, a salesperson couldn’t miss their target more than two time periods in a row without finding themselves out of a job.

    I realize that sales isn’t like the creative work that developers do, or the tedious work of managing systems, but what if we were treated like salespeople? Do you think you’d want to work in an environment where you had some quantifiable measurement, such as uptime for a quarter, plus tickets closed, and if you couldn’t meet the goals, you’d be let go from your DBA position?

    Imagine if you were a developer. You might have the demand that you meet the expectations for delivery and you are held accountable for estimates within some amount of variance. Perhaps as a developer there would be a requirement to complete xx amount of stories in some time period. I don’t this would work well. I think we’d try to make longer estimates and more granular stories to better define out work, but I’d also expect the business might press back and put more pressure on us.

    In plenty of organizations, there are these pressures. I certainly see developers working harder to get things done, not because of the threat of their job, but because many of us that choose technical work feel a sense of pride and responsibility in the work we do. We work long hours to meet deadlines, sometimes because we’re afraid not to, but usually we do want to complete our projects in the best way we can.

    I think we’d all be worse if we were treated like salespeople, and likely many of us would have more job changes. I also think our organizations would suffer more, with higher turnover and a lack of detailed institutional knowledge among those that build systems. Certainly some high performers might thrive, especially if we received large bonuses, like salespeople often do, but I also think we’d find shoddier work overall, with applications even more cobbled together with patches and prayers, with the hopes that our workload doesn’t overwhelm our systems.

    I know I wouldn’t like working in that type of environment, and why I’m not sure I’d ever want to go into any sales role.

    Steve Jones

     

  • Avoiding Development Taxes

    When I first worked in an environment where multiple developers needed to release software, I found too many rules and constraints for smooth development. The process was developed by one person, or for one application, and somehow expanded to encompass all work being done in the organization. It was if we weren’t trying to think about our creative work as developers and DBAs, and instead viewed our systems composed of widgets built in a factory, each one a copy of the others, perhaps just a bit bigger or smaller. We used the same set of rules for the mission critical finance program as we did for the department vacation scheduling application.

    While working inside an overreaching command-and-control mentality, the idea of moving faster or releasing software more often was seen as really dangerous. Two decades of Agile methodologies, and the rise of DevOps have started to change this for many companies. Each year the State of DevOps report seems to show more and more organizations finding ways to build better software, often by having their operations people embrace the concepts and processes used by software developers as a way of building and managing their environments.

    Databases still lag behind, and as Donovan Brown says in this piece, if you’re not automating the back-end work of code deployments to the database, you’re still “faking” some of your DevOps process. Databases must maintain the state of data, even as transactions take place around code changes. Ensuring that we properly handle those data changes is a challenge. However, by treating the database changes as similarly as possible to application changes, we can minimize risk and learn database development techniques that help us push forward without being reckless.

    Tools have gotten better for database development. Microsoft has some tools for SQL Server, and various other vendors such as Redgate have others. Good tools are essential, but each new one adds some complexity to the environment. That’s one reason why having a minimal number of tools and platforms reduces the friction of getting things done. I see this as a big reason SQL Server on Linux might take off. Plenty of companies don’t want Windows in their infrastructure when most of their systems are on Linux. Not that Windows is hard, but consistency makes everything easier for a staff.

    This is the same reason why I’d say that it’s worth sticking with a database platform or two and not experimenting with each new type of system that comes out. If your staff knows SQL Server, then adding in MongoDB or Cassandra means there’s a learning curve, or a “tax” as the piece notes, to getting things done. This same tax gets paid with each new vendor, platform, language, or technology you take on.

    Database work is hard, and once your staff gets good at building and deploying changes, you want to take advantage of their knowledge. For companies that have solid development and deployment practices, stick with the things that work well. However, if you have staff that turns over regularly and don’t have a mature process, you can reduce the “tax” you pay for database development. There are companies that have paid some of that integration tax, that learning effort, and they’ve got tooling to help you build code better and faster. Just as I wouldn’t want to code my own build server, I don’t want to code my own database deployment tools. I could, but I’d rather spend my time solving problems and use the tooling that someone else has built to make my job easier, and provide a consistent coding experience for my developers.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Data Bots

    One of the challenges for many databases is getting the information out to our users. Early on many of us had to write queries in a customized fashion for our users. Eventually, reporting systems, such as Reporting Services and Crystal Reports, have been used extensively in many organizations to ease the burden or getting information to users, sometimes even allowing self-service where users write reports. Those are inefficient systems, where a lot of man-hours are spent to create something for users.

    Certainly some efforts are made to allow users to query data in an easier fashion. English Query in SQL Server didn’t work well, but the version in Power BI seems to do some things well. Perhaps it’s because a user can see some of the data and the domain of data being queried is inherently limited. I expect this to improve as services such as Alexa, Siri, Cortana, and more become embedded into more applications.

    The bots are coming. I used to wonder, but the more I see the advances made in machine learning and related technologies, the more I think that we will continue to see bots used as a way to access our data. There is plenty of hype, but certainly the technologies are being used more and more, and increasingly sophisticated ways. Plenty of businesses are experimenting with them, though it seems in many cases the technology is in an early stage.

    I haven’t been sure where bots are useful, but I see them more and more in places like Slack where a workflow can be kicked off with a chat operation. This is somewhere between running a script with parameters and using a semi-intelligent agent, but certainly the ease of a bot in places like Slack is very interesting. Operations can be easily conducted, with logging and auditing, and feedback, in a way that a CLI doesn’t quite work as smoothly.

    Perhaps it’s because the domain of actions is more limited, I think that ChatOps works better than general purpose bots. I expect that that will change as we find ways to both limit the scope of interactions, perhaps by passing more information along to the bot. I’m certain the context technology for bots will improve, as well the interaction design. In some ways it’s exciting to think about bots being more focused and responsive than today’s customer service representatives. The one thing that I do worry about is the ability to get an empathetic response from a human. A person is more likely to go the extra mile or do a favor than a bot.

    Steve Jones

  • How Long Before You Upgrade?

    This editorial was originally published on Apr 11, 2014. It is being re-published as Steve is out of town, with a few minor changes to dates and values.

    It’s 2017. SQL Server 2000 is 17 years old, but there are still quite of you managing instances. SQL Server 2005 is 12 years old, and I’m sure more of you still deal with that version. I know because I work for a software vendor and I’m constantly asked if our software will run against those two versions of SQL Server. Most of our software is no longer supported on those versions, as they’re too far out of date.

    For many of you, however, if you’re managing a SQL Server 2000 instance, it might only be 10 or 12 years old. Your company might still have been installing SQL Server 2000 in the year 2005. The same is true for SQL Server 2005. I wouldn’t be surprised to find companies still installing 2005 instances in 2008 or even 2009.

    Companies don’t care much about versions. They tend to mostly care about databases getting the job done, and sometimes, support. Many organizations don’t see value in upgrading too often because of the overhead. I suspect many managers would prefer to get many years usage out of a platform before they change in order to minimize work that doesn’t add value to their business.

    The question this week asks you about the longevity of your database instances. Think about the average instance, or even the majority of your applications and how long they will remain on a particular version.

    How many years will you run a platform before you upgrade it?

    Years ago I heard someone at a large Fortune 100 company say their stated policy was to get 10 years of service out of a database server. At the time I thought that was a long time, but the more I think about it, the more I think that might be a minimum amount of time I’d want from a platform.

    Let us know this week what you experience, and perhaps what you’d prefer.

    Steve Jones