Voice of the DBA

Category: Editorial

  • The Build Book of News

    Every year Microsoft has held the Build conference for developers. I’ve been lucky enough to go a few times, and I was hoping to get the chance to attend again. With the pandemic, the entire event went virtual, and was held across 48 continuous hours. I was slightly disappointed as a few sessions I wanted to see were early in the morning or late at night, but I am sure most of these will be available on demand later, so I can watch them if I wish.

    One of the things Microsoft has done is produce a Build Book of News, a 55 page PDF book of all their announcements and changes. You can download it from Paul Andrew’s blog, or you can look at the announcements online at Microsoft News.

    I randomly watched Build on and off this past week, having some of the sessions in the background while doing other things. There certainly were some interesting sections, though not a lot of data platform focus, but I found a few items that you might like.

    We’re all remote now, or the majority of us are, and I can see that remote tools are
    important. I know there has been some remote code work in Visual Studio in the past, but I didn’t think many people would use it. Now in watching some of the remote code demos, I think these tools might be interesting, especially when a few people are trying to debug a crisis situation. Being able to see the code on my own machine, and seeing what others might change or think is a better (or worse) solution could be very helpful.

    The mobile GitHub tools for review are getting better, and that’s good. Since it’s likely more of us might be in different locations, on different schedules, the ability to approve a PR could prove really helpful. Codespaces are especially interesting. Maybe not so much for databases, but maybe. I wonder if we could easily get data provisioning in here.

    Azure CosmosDB is still something I want to play with, though I’ve been hesitant to set up a db because of cost. Serverless CosmosDB might get me to try something. I have no real excuse since they’re an emulator, so maybe not. I wonder how many of you might try CosmosDB out. There are also announcements about PostgreSQL and MySQL on as PaaS services getting feature parity with SQL Server in many ways.

    Lots of Synapse changes, which might be of interest to those of you with larger warehouses and looking to take advantage of the cloud offering. Quite a few AI changes as well, with Bots, speech, ML, and more. I especially liked the keynote on AI, which I think was interesting. It provides some vision of what could be possible.

    Tons of developer sessions, and I’d suggest that you browse or search the sessions to see what interests you. There aren’t a ton on demand as I write this, but likely more will appear this coming week. I hope the Cloud Skills Challenge will also remain up there, as I’d like to spend some time experimenting with services. If you haven’t worked with the Azure services, I might give that a try and get a feel for what’s possible.

    Build is always interesting, and I’m not sure if I love this virtual format, but I’m glad the event was still available and once again I’m impressed with all the work Microsoft is doing to help developers build solutions.

    Steve Jones

  • Investing in Speed

    While most of us might not want to start our own company (or maybe we do), we can learn a few things from those that do. Building something new, being efficient, effective, and quick are skills needed when starting a company. I’ve read a lot about how companies are built and entrepreneurs work. Lately I ran across some advice from Daniel Gross, the founder of Pioneer, a former partner at Y-Combinator (from David Perell).

    Many of us are financially careful. We often are careful with how and where we spend money at home. I find lots of tech professionals frugal at work as well, often being careful with their budgets, or even with the requests they make of managers. That being said, here is a great quote:

    “Overbearing frugality prevented me from spending any money, which creates inefficiencies. Spend like a king on speed, like a pauper on everything else. Faster computer? Go. Faster Internet? Go. Better sleep? Go. Expensive dinner? Stop. Expensive dinner to close a candidate? Go. If you can, use your capital to move faster. Your competitor is taking the shorter flight. Book it.”

    Often I see companies get caught up spending or not spending based on some ideas that don’t have anything to do with efficiency. They don’t invest in things that improve the business, but invest in things they like, or avoid things they don’t like. I see this with choices as well, where a professional or manager may want to change a tool/platform/etc. because they like one over the other. Often without any good fundamental reason.

    Spending money isn’t bad if you are investing in driving your business forward. Learn to make that distinction and don’t be afraid of making good investments. It’s fine to indulge in anything, but in moderation. That might be the key to success for many hings in life.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Rolling Back One Bug for Another

    I was working with a customer recently that develops software for use by their clients. They work in a DevOps style flow, regularly completing work and sending that to their clients. In one case, they released a hot fix quickly to resolve a bug in their software. In this case, the developers received the report, triage’d the bug, and released the fix in less than a week. Their clients were happy with the response and speed at which the fix was delivered.

    Unfortunately, they also released another bug with the fix. The new bug was in an unrelated area of the software, created by separate changes to the code. Now they had a dilemma. The hot fix helped some customers, but the fix also broke some things that other customers cared about.

    What do you do here? If you were in charge of this software team, how do you decide what to do? You can pull the patch, but that means some clients might have broken software. You can leave the patch out there, but then you risk other customers being upset by a new bug.

    There isn’t a good solution here, and the more clients you have, the more likely that you have a large split of customers wanting version 1 versus those wanting version 2. You could rebuild the hotfix to remove the new bug, or you could make another patch that just addresses the second bug. The latter idea is what DevOps would suggest, with a roll forward to a third version of the software. The idea being you keep improving things and fixing bugs as you continue to develop new features. You will release some bugs, but you can fix them quickly.

    The downside of this is that if you release too many bugs, customers are loathe to upgrade. When this happens, you start to find yourself having to support many versions of your software. If you respond to customers with special patches that only fix bugs without adding features, you may end up with many more versions than you can track, which can be a real nightmare for developers to manage.

    How do you deal with patches causing bugs? I recently re-read a piece by Eric Sink in which he recounts releasing three maintenance versions to his customers in a week. Embarrassing for a version control vendor. It’s a good (but long) read, and one that might give you some perspective. We can’t squash every bug, and we can’t test for everything, but we can work to continue to improve, chasing the dream of bug free software. Or at least, regression bug free software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Challenge of Chat

    I’ve followed 37 Signals (now Basecamp) and Jason Fried for years. I think they’ve built an amazing company and have a philosophy on business and life I admire. They’ve written books, and they blog often. Recently I saw a post on chat, which is something that I’ve struggled with at times. Even before this work-at-home-at-scale experiment we’re all living, the challenges of everyone reaching out have weighed on my mind.

    Without an office that physically concentrates many people together, many of us are only communicating electronically with our coworkers. We’ve had email for years, and video conferencing is growing in use, and some of us have had instant messaging for years.  It seems that chat has become more pervasive and the ability to reach out with live, interactive chats is something that has become expected in many organizations. Whether this is on Slack, Teams, or some other channel, there is some good and bad with the medium. I think the post highlights the bad outweighing the good, and it mentions a few things I hadn’t thought about.

    I do have Slack running most of the day, and initially I found it to be exhausting and distracting. I think I also knew chat might create some implied consensus and lessons deep thought, but I hadn’t thought much about before reading this post. Chat has been a great quick tool for questions and answers. I often use it to pose a question about how some feature in our product works, not necessarily getting an immediate answer, but also having this work better than email as a developer can pull the question rather than it being pushed to them. It works well in threads, but not very well if responses aren’t tied to questions.

    At the same time, there are enough distractions for most of us, and having more of them randomly appear throughout my day has been an issue. Over time, I’ve learned to utilize some of the advice in the piece. I ignore lots of channels and just mark them as read often. I’ll take bigger discussions into email or a meeting, and I’ve learned to not check this all day. I use it at times, but I’m happy to drop out, and even ignore direct messages if I’m concentrating. It helps I have most notifications turned off.

    Attention is limited, and like time, it’s a valuable resource. As you work alone, there might be more of a need to interact and engage with others, but recognize it for the productivity drain it can be.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.