Voice of the DBA

Category: Editorial

  • Collecting Toxic Waste

    I was listening to someone talk about software development recently and they used this phrase: “are you collecting toxic waste?”. In this case, they were discussing technical debt, but I found the analogy to be good. I’ve often thought that long term technical debt can make a software project extremely question.

    The speaker in this talk had two questions, which I found to be good ones for software developer. The first was are you optimizing individual projects at the expense of longer term technical debt? This is a good way to think about each decision you make about how to build a feature. Asking yourself about short term, or limited scope thinking v longer time thinking is important. Often if we take fifteen minutes and discuss the future of a decision with colleagues, we can better view the trade-off. There are good reasons to sometimes implement something in a short term, fashion, but not every time.

    Even if we discuss with ourselves, perhaps by writing down the pros and cons, you might think through your issues. I often find that forcing myself to explain a concept helps me better understand it. It also helps me communicate better with others when I have to work through the issues. Of course, it is very easy to miss something or skip steps when you do this for yourself, I really, really recommend you get feedback from another person.

    The second question is are you tracking technical debt or finding ways to pay this down? I think this is one that you need to periodically revisit. Between sprints, maybe after mid length period of time has passed, review the items in your system that you’ve compromised on. Maybe you look at code no one wants to touch, or is afraid to touch. Maybe this is examining inefficient code, which is something that is crucial in a database. While a poor query might suffice with low volumes or data, or limited numbers of executions, this can quickly become a problem, especially as the number of inefficient items grow.

    The database suffers from often being a bottleneck, a single place where all clients connect. We often do have powerful systems here, and the platforms like SQL Server make efficient use of resources, but bad code and technical debt become problems. I often find broken code in database that can’t even be executed, and along with poorly written queries, this can hamper future development and flexibility.

    Periodically review your code, looking for things to remove or improvements to be made. Your future developer self will thank you.

    Steve Jones

    Apologies – Podcasts are still iffy with my voice and time. Hopefully after Thanksgiving I get back to them.

  • A Data Request Form

    This week I’m in the PASS Virtual Summit, watching some sessions around other work. Unlike a regular conference, I have more distractions, and I have other commitments. So while I have to be around to deliver or chat during a few sessions, and I am at the Redgate Booth, I also still have other work to get done. Being ill for most of last week put me way behind.

    As I was wandering around the Virtual Summit site, I’ve been experimenting and clicking, looking for how things work. After a little discussion on Twitter about the privacy policy, I was looking for what the platform offers. The vendor being used is Cadmium CD, and at the bottom of the Summit pages, there is a link that says “My Data”. Clicking it takes me here: Data Request Form.

    This is what is says. You can request all your data from the vendor, which is a provision of the GDPR, allowing you access to what data is being stored about you. You can also ask to be removed, forgotten, or transferred. I wonder if that last one will become a service item. Would you subscribe to somewhere that gets copies of and cleanses, analyzes, etc. your data, letting you know what mistakes or inconsistencies are out there? Or what is being tracked, with some privacy surface area or areas of concern?

    I don’t know if I would, but I do like the idea of being able to request my data. I’ve done this from some places, getting a look into how I have used services more than what people are tracking, but knowing what’s being captured and held is a concept I might embrace.

    Steve Jones

  • The Virtual Experience

    I just completed the 2020 DevOps Enterprise Summit a few weeks ago, and it was enlightening to me to see that so many people liked this experience. They appreciated not traveling, being able to drop in and out of sessions while near their home and family. I found that lots of people also liked the MVP Summit last spring, which was also virtual.

    The PASS Summit went virtual recently, and I went through an all day pre-con as well as a few sessions during the week. As many of you, I’m a bit screen and Zoom fatigued, and while I enjoy learning and seeing people passionate about a technology, I’m tired of seeing it inside these four walls.

    I worry that I’m in the minority. I recognize the value of the inclusion of those that don’t have the time or money to attend a conference live. I appreciate that the ability to watch when and where it fits into my schedule. I love that others can pause, rewind, get captions, and more that spread knowledge out.

    However, I think we’ve lost something, and certainly lost some of the collaborative, discussions and debates that we can have in live events. While I can reach out and discuss with anyone, it’s hard to discuss with just someone. Others can join in, and semi-private channels, and especially the times during breaks when I can get up and walk while talking, are things I miss in the virtual experience.

    If virtual events were spread out more, and not everything in my work world were virtual, perhaps I would feel differently, but for now, I don’t love the virtual experience, and feel it’s a pale shadow of a SQL Saturday, user group, or live conference. I hope that this isn’t something I do too often, but I suspect this will be a permanent part of our lives forever.

    Steve Jones

  • How Do You Experiment?

    One of the things that DevOps asks software developers to do is experiment. Try new ideas out, get feedback quickly, and then choose how to grow or stop your experiment. This is great for features, and it works well for application software.

    The general flow for this is to talk to customers, and then decide what to build. In some sense, this can work, but as I heard at the DOES Summit recently, if Henry Ford had asked his early on customers what to build, they’d have asked for a faster horse.

    Customers are limited by their current experience. This includes not only end users, but for us database pros, the developers that build software. When they want to experiment, they often need some backing from the database to store information and query it.

    If we want to help enable experiments, and allow our software to evolve, there are two things we need to deal with in experiments. One is schema changes, either through new data buckets in tables, or programmable objects, such as views, functions, and procedures Adding these, or removing them when experiments aren’t useful, can be cumbersome and difficult. It’s amazing how quickly we create dependencies and how slow we are to remove them.

    The other area is in ensuring that we properly or appropriately, handle resource usage. Do we go back and tune queries, or restructure the way that we’ve indexed items to ensure that our system works optimally? Some tuning can be done early, and should be, but some requires some feedback to understand query patterns or data loads.

    Today, I’m wondering how, or if, you experiment in database work. What works for you, or what doesn’t? Or do you hate the idea of experiments in the database world and want more specification up front? Let me know with a comment.

    Steve Jones

    Note: Podcasts are suspended for a week as I deal with the PASS Summit.