Voice of the DBA

Category: Editorial

  • Always Retry

    When multiple people connect to a SQL Server database and attempt to query or update rows, blocking occurs. This is normal, and we expect a certain amount of this, usually very short lived. If it’s not, then having tools that monitor your database and can quickly let you know which connection to kill is important.

    There are also issues like network hiccups and deadlocks, which can cause a transaction to fail and roll back. In these cases, the application should retry a query, often quickly, without bothering the user. This isn’t something that most developers code into their applications, though they should. However, is this something that lots and lots of developers ought to learn and re-implement over and over?

    Microsoft has released a preview of a configurable retry logic in the SqlClinet driver for .NET (others coming soon). With this enhancement, developers can tell the driver how to react with some types of connectivity errors and perhaps resubmit the query. There are various options you can read about, and you ought to carefully test and you decide to use before you deploy them to production.

    To me, this is long overdue. Software ought to work for us and make our work easier, including easier for software developers. Often I’ve heard many vendors point to the configuration options and flexibility of their software, tool, or framework, while placing the burden on developers to write a lot of the code to actually take advantage of the tool. Whenever possible, we ought to make the preferred choice, the best practice, the most common code an easy choice by making it easy to add to a system. Give people flexibility when they need it, but make it easy for them to see the benefits of your software quickly.

    Steve Jones

  • Bug Management

    All of our software has bugs. Some bugs are just bad code, some are incorrect specs, and some are things the client thinks should work differently than the way the application is built. In any case, we know there are plenty of bugs in software.

    How companies handle bugs is interesting. Some feed these back to the current developer team. Some use junior developers to do bug work. Some have support teams that focus on bugs and coordinate with developers.

    What if you get parts of your software from another source? More and more developers are using open source libraries, packages, frameworks, and more. How do you deal with bugs in those situations? As someone that has worked in this manner, tackling those bugs yourself is problematic and introduces other issues with your software development pipeline when the upstream source is updated.

    Google is taking a different approach, actually assigning developers to projects that they need. One example is in this piece, about a couple developers assigned to the security of Linux. While the headline is that they keep finding lots of bugs, the more interesting part to me is that Google internally builds the OSS they use from source, add in their patches, and then use pull requests to get them accepted into the main project.

    I don’t know that many of us can afford to sponsor a developer to contribute to a project full time, but I do like the idea of using a fork to build your software from source. This might not prevent bugs or malware, but if you are hit in this manner, you know that lots of others will be as well.

    Steve Jones

  • DevOps in Space

    Some of the early science fiction books I read were by Robert Heinlein, often including rocket ships and space travel. These days I’m uninterested in actually going to space, but I am excited by the prospect of the efforts being made to send others. It’s an exciting time to be interested in travel off of this planet.

    One of the headline makers is SpaceX, which has had quite a bit of success launching reusable rockets carrying all sorts of cargo. My son was very interested in their work as an 18 year old, and I still remember taking him to Cape Canaveral and watching the first first rocket launch and land at the facility. An exciting time for us.

    SpaceX has adopted a DevOps attitude towards their physical rockets, adapting and iterating quickly to improve their designs. The pace of progress is quite interesting, analogous to how some companies have changed their software development lifecycle practices, becoming quite adept at building and improving applications in a rapid fashion. Alex Yates draws some parallels, and includes lots of fascinating rocket information, in this post on the Octopus Deploy blog.

    One of the big challenges I find with changing software development is that we struggle to let go of old practices. Even as we look to iterate, often we are unable to accept risk, and we often want to stick with the “always done it this way” for some things. While we might accept some changes, we don’t accept others, and may even cancel out the benefits of automation improvements with a lack of willingness to adapt our culture.

    I do hope that other companies challenge SpaceX, and learn from them. Ultimately we do better with a competitor that forces them to continue to improve and not rest on past success. The same is necessary for software development teams to continually improve. If your organization is stuck in a rut with software development, request (or push) for a team to try something new. To adopt and grow with DevOps. Make them prove they can build, deploy, and operate software in a better way. Then challenge other teams to try and adopt their ideas, and then improve upon them over time.

    Steve Jones

  • Easing Back to the Office

    Much of the tech world moved to remote work last year when the pandemic started. Various companies started to announce future dates during which they’d guarantee workers the ability to work from home. That was helpful, as many needed to plan for child care, parent assistance, and more. My company kept pushing the date out, and early this year (or late last) said that we would have the option through all of 2021.

    Microsoft had various announcements, but one was that employees could work from home permanently. For less than 50% of their time. The headlines downplayed the restriction, though I was glad to see some flexibility. Now, Microsoft is starting to allow some workers back to campus, noting that they are on step 4 of their 6 step dial. This is 57,000 workers, which is quite a few. Masks and social distancing are still required.

    While a good portion of employees want flexibility, and many prefer remote work, there are a good number that want to return to an office and be around other people. While Microsoft, and my employer, both want to embrace the changes of the last year, finding a balance between the past and future is hard. I thought that Microsoft’s blog on embracing a flexible workplace echoes a lot of what I hear from my company and a few others. We want to work with you, but there might be some restrictions. Certainly tax implications are a part of this for my company, and perhaps for Microsoft as well.

    I honestly am not quite sure how I want the future to work. While I appreciate remote first, and I like the idea of everyone being somewhat a peer during meetings, I also value getting people together. I don’t really look forward to going to an office and logging onto Zoom from a desk. I want to see people in conference rooms, able to discuss, debate, and brainstorm solutions for the future.

    For technologists, this might be easier. I could see more whiteboards, like Mural, in use in meetings, allowing remote people to participate in similar ways to those in the room, but I until we get something that creates some sort of virtual presence, I’m not sure that we will really see a good blend of in-person and remote attendees. I hope companies work on solutions like this, as the world has changed and in person attendance will still matter.

    Steve Jones