Voice of the DBA

Tag: software development

  • 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.

  • 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.

  • Building Quality In

    I heard someone at the 2020 DevOps Enterprise Summit conference say that quality needs to be built in. That’s something that many, or hopefully most, of us believe. Everyone ought to do quality work and build it into their daily tasks. However, the person speaking went further and defined this in a way I like:

    “Building quality in means we don’t pass quality issues along to others.”

    That’s a much better definition for me. This implies that there are effects if I don’t do a good enough job. If I knowingly pass along an issue, that’s a problem. I haven’t done quality work. I’d likely say that if I don’t bother to test or evaluate my work in some way, I’m essentially doing the same thing.

    We all write poor code, or do a job poorly at times. Often this comes because of ignorance, naivety, or just a lack of skill. That’s understandable, and we can forgive a person not being able or ready to do a job at the same level as a more experienced person.

    However, that should be a learning and teaching moment. We don’t expect continuous quality issues, certainly not of the same type. A big part of the DevOps movement, and other modern software development methodologies is learning from our mistakes. Getting better. Improving the quality of our software.

    Don’t just get work done. Don’t just close tickets or move a sticky note. Learn to do better each time you make a mistake. Learn to write better code or implement better processes. Learn to build in quality.

    Steve Jones

  • The App Compatibility Promise

    I was listening to one of the Ignite keynotes, and I heard an executive say something about “if your app doesn’t work, we’ll help you fix it at no additional cost, or fix Windows.” I had stop and rewind and check, and then go look around. Sure enough, there is an App Assure promise for Windows 10 and apps.

    This isn’t just for commercial software, but it lists custom line-of-business apps, third party apps, and more. Now, this doesn’t appear to be for everyone. The eligibility for at last the FastTrack portion of this is 150 or more licenses of Windows, Office, etc. However, it is a guarantee that they will help you.

    There’s also a note that there isn’t a requirement for ISVs building Windows 10 apps. To me, that means there’s no good reason why more companies don’t take advantage of it. I do think, however, that there’s a missing component here.

    Big parts of the Ignite keynotes, and in Microsoft’s marketing and messaging, is about data. That should mean that SQL Server and CosmosDB ought to be included in this promise. If there are regressions or bad plans, I’d hope that Microsoft would help them fix things. Or maybe promise that the compatibility mode would insulate apps.

    I know that execution plans regress, sometimes on the same version, and guaranteeing performance or a plan across versions isn’t likely possible. However, I do think that Microsoft could provide more guarantees, perhaps with some caveats that if they need you to change code you will.

    We all know that we need to test, test, test to ensure we aren’t introducing regressions or other issues. This isn’t a panacea, but it also isn’t a project. It’s an ongoing part of building any software, including database software. Many of us do this, but it becomes harder and more complex for ISVs that often deal with many versions. However, we pay lots of money, and I’d expect that they at least are supporting patches to existing software. I think that’s part of an informal contract that they ought to believe in.

    Listen to the podcast at Libsyn, Stitcher or iTunes.