Voice of the DBA

Tag: software development

  • The Responsibility for Bugs

    Most software has bugs. Actually, maybe all software has bugs, but often we can live with some of them. Over time, vendors regularly issue patches to fix things, and despite these issues, many of us continue to use software productively, if not happily. We live with some workarounds or issues, and continue to get work done, entertain ourselves, and the world keeps moving forward.

    Recently a software developer issued a full refund to customers that had been running into issues with their software, in this case a game. Apparently this is more of a platform issue, as the early reviewers saw the game on a PC, and many of the complaints are on dedicated consoles. The developer of the game has promised patches to fix the main issues, but if customers want a refund, they can get one.

    I’ve had issues with plenty of software in the past, as vendors release a new version that might not have been tested as well as it should. I’ve also seen plenty of scale issues, where software is tested or architected for a certain scale, but customers use it at larger scales. My work with large enterprises, showed the latter to be the case more often than I’d like.

    In the case of the game, the public outcry can cause lots of changes, mostly because the goodwill and reputation of the vendor are at stake. However, in many enterprise software sales, there isn’t a public disclosure of issues that prevent other customers from learning of issues. Part of this is a lack of detailed public reviews of software, and part of this is that users don’t often share specific issues outside of their organization.

    I wish more vendors were held accountable for bugs, and with responsibility to patch and mitigate them. However, I also see that software is used in so many different ways, with many configurations, that it can be hard to comprehensively test everything. I also know that there are bugs that very few customers hit, and the cost to deal with these can be high.

    Ultimately, I think I’d like to have more transparency required about which bugs customers hit and in which environments. I’d also like to have some requirement that some percentage of bugs must be fixed within a timeframe or customers entitled to some compensation. I know this might lead to many simple bugs fixed, but perhaps it would also pressure software vendors to improve their quality a little more than they do today.

    Steve Jones

  • Speaking: Tech Community Day 2020

    Delivered a Keynote talk on the Future of Database Development.

    Local schedule link

  • Practice Your Skills with the Advent of Code

    It’s that time of year, when the Advent of Code goes live. It started this week, with a few exercises released last week. You can still join in, and even go back and look at previous years (2019, 2018, 2017, 2016) and go through them. It’s a good exercise for your mind.

    To be fair, I’ve never completed the challenge in any year. Usually life gets in the way, and I get distracted. I’ve gotten through 15-20 in some years, but often the time required to work through the complex algorithms gets me a little discouraged. I’m not a 10x programmer, but I try.

    One thing I’ve done most years is to try and work through the problems in multiple languages. Typically my choices have been to try and solve each item three times, using T-SQL, Python, and PowerShell. I find it interesting to compare the languages and see how to handle the test data and also get the solution to work in each environment.

    If you want to stretch your programming mind and have some fun, give the challenge a try. Posting your solutions to a blog or even open a GitHub repo (or other VCS platform). It’s a good way to showcase your knowledge, at whatever level it is. You might even learn something if others comment on your solutions.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Technology Collapse

    This past week the Arecibo radio telescope collapsed, with cables and instruments falling into the massive dish. You can see images of the devastation, which saddens me. I doubt this will be rebuilt, though one can keep hope alive. there were reports of failures a month or so ago, with the intent to shut down the telescope, remove instruments, and institute a controlled demolition.

    The facility was featured in a few movies, notably GoldenEye and Contact. The latter is one that first showed me the telescope, which I first thought was a movie magic trick. When I found out this was a real facility, I was amazed that humans could conceive and build such a structure. Even more amazing is that it was built in the 1960s.

    That’s quite a lifetime for a piece of technology. While I’m sure lots of wiring, electronics, computer systems, and more were added or upgraded, the core of this telescope remained the same. The ongoing engineering effort, fitting new capabilities around legacy systems and structures, was likely a study that many would find interesting.

    I don’t know many database systems that have survived that long, but certainly there are some long lived legacy applications. The Sabre reservation system for airlines is one that stands out to me. The history of this one is fascinating, especially as it’s a system I’ve depended on in my travels.

    Many of us that work with databases likely feel that everything we do is a legacy system. The dependencies our objects have on various applications, scripts, reports, and more can limit how much repair, improvement, or replacement we can make to schema.

    There are good techniques for modifying our objects, and helping to ensure we don’t break systems, but we often do need some cooperation and collaboration with application developers to implement those changes. Much of DevOps avoids talking about the database, but we shouldn’t. Instead, we ought to embrace database refactoring patterns, both at the database and application levels, ensuring that our systems can survive for as long as we need them while adapting to the changing requirements of our clients.

    Steve Jones