Tag: software development

  • ConFoo–The Future of Database Development in Containers

    I delivered a talk at the ConFoo conference. I’ve never been to this live, and when I submitted last year, I was hoping this would somehow be a live event in Montreal. It didn’t happen, but I joined the virtual event and gave my presentation.

    The deck is here: FutureDBDevelopment_confoo.zip

    No real questions, but lots of interest, which is great.

    If you didn’t stay near the end, I talked a bit about the Spawn.cc project and the journey the research group has taken to learn about Kubernetes and file systems. It’s been fascinating to watch the project evolve. The API used to change almost weekly as it was improved and enhanced.

    A few resources:

  • Remembering the Past

    Just a short time ago, the SQL Family lost Gareth Swanepoel. It was fairly sudden and sad to have someone I knew fairly well pass away. He was the first person that I directly knew that was lost to the COVID-19 pandemic.

    I’m getting older. I seem to hear about a person I’ve known passing away almost every year now. I know I’ve got more life behind me than in front of me, and I cherish the moments I do have and the memories of others.

    A few years ago Andy Warren and I were talking about this subject. This was after we lost a common friend, and we wanted to have some way to remember them. We kicked around a few ideas, but other than adding an “Obituaries” category to Database Weekly, I didn’t do much.

    I decided to change that after I heard about Gareth. While processing my grief, I bought sqlmemorial.org and started to put something together. I’ve been hearing about Jekyll and I spent a little time messing around with it. I ended up deciding to put this up and start ensuring that we have a way to remember the people that have taught and touched us. I’ll also share some articles on how I put this together.

    I set this up as a GitHub repo, and I am taking pull requests for people that want to add a memory, a link, a picture, or something else. I’m also hoping that people will let me know as others pass, a sad fact of life that we will continue to experience in the years to come.

    I’m hoping this helps me, and many of you, fondly remember the people in our SQL Family.

    Steve Jones

  • 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