Voice of the DBA

Category: Editorial

  • The Separation of Tools

    I’ve got a question for you today. Is it better to have SSMS and ADS available as separate downloads?

    If you installed SQL Server prior to 2017 (the year, not the version), you had the option to add Management Studio (SSMS) to your installation. In fact, that was the only way to get SSMS back then. There was no separate tools download, which was a pain for many customers.

    Since then, there have been multiple releases of SSMS separately, starting with 16.x and moving through v17 and now v18. In fact, it’s been roughly every quarter we’ve gotten new releases of the tooling. In addition, we’ve gotten Azure Data Studio (ADS), which is based on Visual Studio Code, but built with connections to the data platform as the primary goal.

    There are now separate downloads for SSMS and ADS, though the latest SSMS download notes that starting with v18.7, ADS is automatically installed alongside the tool. That generated a feedback item, which requests that this bundling be removed. While I don’t find this to be an issue, I do understand that this can be a problem for many organizations.

    I think that Microsoft moving to provide a more customized and flexible tooling experience makes sense. Give us the options to configure our systems as we desired. Let us add new features that are appropriate for us, or easily remove them from the install. I would include the requirement that ADS be installed with SSMS, as noted above. That being said, the ability to add in various extensions might be of concern to many organizations. Flexibility includes the ability of both users and organizations to control the allowed and prohibited list of features.

    I will admit a fondness for SSMS that ADS has not replicated, but I do find myself using it more and more as new tooling items are available only in ADS and not in SSMS. Perhaps as I use notebooks more, I’ll find myself more enamored with ADS. After all, I loved isql/Windows for years, even when other tools became the standard.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Spookiest Year

    Last Halloween I was in Chicago, in one of the biggest cities in the US visiting a customer. This was near the end of a very busy travel year, where I’d been to England 5 times, Australia twice, and was returning home for the weekend before heading back out on a trip to Seattle for the 2019 PASS Summit.

    This year I expected more of the same, even into early February, before the COVID-19 pandemic hit the world. Since then, much of the world has changed, certainly travel, conferences, SQL Saturdays, and most other types of gatherings have changed. Not just work events, but work itself, with many of us, perhaps most, working from come. Concerts, comedy, sporting events, and more have been cancelled or changed to taking place without spectators. While some things are starting to come back, they’ve forever changed.

    I have started coaching volleyball again, and while we’ve started competition, we do so without spectators, which is a very strange experience. As I sat between matches recently, my wife and I noticed how quiet it was and how calm. In a good way, but also a strange feeling for us.

    Perhaps one of the strangest things is watching media more than in the past, and seeing people without masks, in crowds, living life in a way that I assumed would always exist a year ago. It’s certainly jarring, and I wonder to what extent we’ll return to that world in the future.

    Tomorrow is Halloween, and while it’s not an event I’ll participate in, I’ll think about the spooky feeling of this entire year, where nothing seems to have gone in the way I’d have expected. I hope that does change in 2021, but for now, I’m assuming we have at least seven more months, through at least April of 2021, living in the same world. Hopefully, I’m wrong.

    Steve Jones

  • 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

  • Lean Coffee

    I read about the concept of Lean Coffee in Making Work Visible, one of the books I set as a goal to read this year. The idea is to have an agenda less meeting, but nevertheless get some things done.

    It sounds crazy, though the format makes some sense. The group takes a minute or two to write down some ideas on paper. Each person then gets two votes to place against the topics. The top rated items get discussed first for a period of time and at the end of that time, everyone votes on continuing discussion or moving on. This can repeat every few minutes.

    I got the chance to experience this at the recent DevOps Enterprise Summit conference, where there were Lean Coffee breaks every day, with each having a topic that people wanted to discuss. One I participated in was fairly rigid, with the facilitator keeping to time, gently encouraging discussion, and rigorously calling for votes.

    While I enjoyed that, a second one didn’t use timers consistently or votes, and the meeting ended up being a rather free form discussion, which was OK, but it meandered and wandered without guidance in a way was somewhat annoying. It was a surprising experience for me, as I typically like free form discussions.

    I don’t know that I’d recommend Lean Coffee for all meetings, but I do like the format, and I think this can be a good way to focus on a few areas a team finds important, especially when there isn’t a clear set of priorities.

    I would encourage you to give it a try, especially if you get into a meeting without a clear agenda. Maybe it’s something I’ll try as a way to discuss and debate some topics at some event.

    Steve Jones