Voice of the DBA

Category: Editorial

  • Take A Vote and Accept Your Loss

    I feel differently today than in the past about many of the things I’ve seen technical people argue about. I’ve written about Tabs vs. Spaces and Singular vs. Plural, and others have debated commas before or after among other topics. While these might be interesting sidebars at lunch, I see them sometimes devolve into time sinks with teams revisiting the issues over and over during their daily work.

    These types of religious wars stifle a lot of productivity and often can linger for years. However, in many cases what I see is debate across weeks or months and then time spent to shift the way that large groups of people work inside of a company. In the last few years, I’ve seen customers argue about which VCS to use, which new CI tool to choose, or even about which secret store to use for their database credentials. Often these debates happen when there is already a technology in use.

    In most cases, the differences between many of these arguments are negligible. Lots of teams fall down on either side of a debate and find themselves very productive. Or not productive, but it often seems the difference is the staff, not the tool, platform, language, or style. Good people are productive no matter which way we choose to work.

    My view is that for most of these items, we ought to have a (relatively) short meeting. Give each side a few days to prepare, but then one spokesperson for each side gets 5 minutes to present their case on why the group should adopt their idea. Once everyone has presented, we debate for a limited time, maybe 15-20 minutes, vote, and then move in that direction. Ultimately, we’re trying to get software written (or deployed or managed or something) and not trying to decide the best way to format that code or choose a tool for CI/CD.

    This teaches people to communicate and learn to present a rational, coherent, succinct idea, which is a valuable skill. This also teaches us to work as a team and learn to accept decisions that don’t go our way. None of us wins 100% of the time in life, so make a good effort to lead others in your direction, but accept that they might choose a different path. In that case, learn to support the team in their efforts.

    The caveat to all of this is that inside of an organization, we often want a standard, so if something is already heavily used, just adopt that pattern or technology.

    Steve Jones

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

  • Hire Well

    In the last few years, I’ve noticed that the quality of technical workers can vary quite a bit in many organizations. I think most people get things done, but often not at a high-quality level. It’s one reason that I write, speak, and try to motivate more of you to work on your skills and your career. I want to see better software being built.

    I tend to work with more database developers than application developers and I tend to see more SQL code than C#/Java/etc. And I see a lot of poorly written SQL Code and poor data models that seem to have been built without a lot of thought put into them. Whether this is because of ignorance or just poor skills is hard to know, but I see a lot of code that makes me slightly cringe.

    Over time, many of us see that this technical debt limits our ability to improve things or make changes. Often these systemic issues linger because the development staff a) doesn’t know how to fix them, b) has other, higher priorities, or c) is afraid to try and make changes. Often it’s a combination of all three, which further limits the agility of the database and application teams. We end up struggling to keep up with customer demands, or we may pile on more and more technical debt. Often this leads to increased performance problems in the database.

    I was reading about development and staffing in this piece, which had an interesting quote: “I currently believe that there’s only one way to buy yourself out of technical issues and bad data models, and that’s buying a really talented engineer whose sole focus is fixing the problem.” Essentially, you need to do two things here. First, hire a smart engineer, and second, empower them to effect change. In many cases, I think you actually need two smart engineers: one database engineer and one application software engineer. Those people have to focus on improvements, refactoring bad data models and the code that depends on them, and slowly raising the level of quality.

    The piece gets a little sidetracked with the way vendors promise their products will fix your problems. In general, that’s not true, at least not without you adapting your process to their software. In my role, I’m careful not to promise more than I can deliver, and not try to minimize the effort required to change. I know it’s somewhere between using 10% time and a major overhaul, and I hope I convey that to clients.

    Ultimately, I think that we haven’t commoditized lots of software development, which is the point of the piece and the quote above. We need to get talented people, or we need to train them, or both. We need people that enjoy their jobs and find some purpose or satisfaction. Part of that is making their jobs more interesting and enjoyable.

    That also means there are many opportunities if you learn to be good at your job. Learn to build good data models. Keep up your skills that write efficient code, learn how to troubleshoot, and learn how to work well with others. None of those are easy skills to develop, nor are they quick to learn, but they can be learned with some effort. Document your progress, blog/write/speak, and I bet you’ll find your career prospects improving.

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

  • Learning NoSQL

    It’s a good idea to learn more about different technologies. I’ve been amazed throughout my career, and even now as someone working for a software vendor, how many different technologies I run into. I’m also amazed at how little bits of knowledge comes in handy, either to help me understand a problem or to help guide others with a recommendation of how to proceed.

    Many of us have experience with relational databases and tabular data. We are comfortable with it, even if we might struggle with a packing problem or using a tally table. However, do you understand how a NoSQL database might be different? Can you even name a few types of NoSQL databases?

    I find it valuable to know a bit and experiment a bit, as your devs may ask you if it’s suitable, or even how to work with one of these databases. They might even start using one and expect you can take responsibility for managing it, backing it up, securing it, and more.

    I wonder how many of you know MongoDB? What type of database it is or how it stores data?  What about Cassandra? Neo-4J? CosmosDB? I haven’t done much work with any of these, but I’ve learned a bit about them. I even spent six months digging into graph databases and learning how they work, how to model data, and how to query them. Part of this was SQL Server’s inclusion of graph structures, but part of this was a customer looking to add graph capabilities to their application. I learned a lot, and even delivered a few presentations on how they work.

    I’m not an expert, but I can have a rational, reasonable, informed debate about the good and bad things with graph databases. Enough to help provide an opinion on whether they might suit a problem. They solve some complex things well and I think they might be a good platform to add to some applications. I wouldn’t get rid of the RDBMS, but supplement it.

    This year I’m going to dig more into MongoDB and Cassandra. We have more customers asking about these platforms and we’re working on Flyway support for both of them.

    If you have any thoughts on NoSQL, or experiences, or even want to write a bit about them, let me know. I’m always looking to learn more, and I always need good authors.

    Steve Jones

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

  • Portable Data Storage

    I saw a review on a rugged SSD, and it got me thinking about local storage. Over the holidays I needed to scan something from a device at the ranch, but to get the image to my computer, I needed a flash drive. It took me 10 minutes of searching around to find one because I rarely use them anymore. In fact, I couldn’t remember the last time I’d used one for a transfer between computers. I just send stuff through OneDrive/DropBox/GDrive or some other mechanism.

    Today I’m wondering if the rest of you have abandoned using portable storage or if is it something you find useful. How often do you use portable storage in your life? Apart from laptops or mobile phones, I’m wondering about portable disk drives or any device where you transfer data using a wire rather than wirelessly. Note, I’m not talking about going from one computer to another on a wired network. I mean moving the storage from one place to another with your hands.

    The only place I know I’m regularly using a portable drive is in the Tesla. There I have a rugged portable SSD that captures the dashcam and security footage. I had to transfer it from the drive to my computer last year when I saw an accident. I think that might have been the last time that I actually used portable storage (before the scan).

    I have lots of old portable drives, and even old CD/DVDs I’ve recorded that have SQL Server ISO, pictures, backups of databases, and more. However, I don’t use them anymore. I don’t know how many of those devices still work, and I ought to check them, load the backups into cloud storage, and then recycle (after erasing) the devices. Or trashing them. I’m guessing many of them are just old tech at this point no one wants.

    I think the era of using portable storage most of the time is likely gone. Even my friends who like to keep their own backups locally tend to use a NAS of some sort and wireless transfers, as opposed to plugging in. However, maybe I’m wrong. Are some of you still Luddites with storage technology, if that word can even apply to digital storage technology?

    Steve Jones

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