Voice of the DBA

Category: Editorial

  • Sharing the Code

    I don’t know how many of you use the ScriptDOM. I haven’t really used it, but was very impressed with Mala Mahadevan’s Stairway Series on the topic. I have recommended this to a few customers that were looking for some complex code analysis features, which go beyond what SQL Prompt or SQL Fluff do.

    I noticed this week that ScriptDom has been open sourced by Microsoft. The code is available on GitHub, which means you can fork it and change it. Or submit PRs. No idea if Microsoft will take them, but if you write solid, useful code, they might.

    I like that more and more Microsoft is open-sourcing and sharing code that they write. Usually, their repos aren’t for software they sell, but maybe they will change that at some point.

    There are over 5000 repos in their account right now, including one for VSCode, which I use almost every day. While I don’t plan on contributing or even bug-fixing, I bet some of you might. I might contribute to the docs, which I do regularly for the SQL Server docs. There are a lot of changes here, but there are a few marked way0utwest.

    BTW, if you don’t want to do your own PRs, send me a note. I’m happy to edit the docs and submit changes.

    I am a fan of open-source projects, because I do think collaboration is useful in many situations. While I don’t expect many people to actually make changes to software, some will. Some, like me, will correct docs, and others will find issues in the code and report them. All of those efforts help us improve software, and I am all for higher quality software.

    Now if we could get Microsoft to open-source SSMS, maybe a few of you would find ways to improve that application.

    Steve Jones

  • The Survivors

    The last year has seen a number of large tech companies lay off large numbers of staff. The list for 2023 includes large companies, like Google (12,000), Amazon (9,000 this time), Microsoft (10,000), and Meta (10,000 this time), but also small companies like Zoom (1,300), Rapid (115), and Roku (200). It’s not just tech companies, however, as Disney (7,000), Gap (500), 3M (6,000), and David’s Bridal (9,236) are letting people go. There are plenty of other companies who have let people go, which is interesting to me as the economy has grown in the US, though profits were down. It’s hard to know whether these layoffs are really important for all these companies or whether these layoffs are management’s decision to group their bad news with everyone else’s and take advantage of the opportunity to shrink labor costs.

    In any case, layoffs are sad and stressful. Certainly, the people being let go are traumatized and I don’t want to minimize the impact to their lives, but this can be hard for the survivors as well. This isn’t just a Silicon Valley situation, but one that affects many employees all over the world. Whenever there is a large staffing change in an organization, those that remain can be traumatized and unproductive. This is one reason that public companies must notify and disclose layoffs to investors.

    This article looks at how some tech company employees react after surviving a layoff, and it reminds me of some of the layoffs I’ve been through. While I haven’t been let go in a layoff, I have had to deal with the aftermath of some friends losing their employment while other friends try to cope. I’ve felt sad, angry, upset, concerned, frustrated, and more. Even as one of the lucky people that kept their jobs, I found myself unable to cope with the changes on the fateful day and for some time after. I struggled to focus during the next few weeks, while also being stressed as I realized the workload grew unexpectedly. There was still lots of work, but less staff to do it.

    Anytime you survive a layoff, I think it’s natural to question whether you want to continue working in the same organization. Is business that bad that we need to let people go? Will there be another layoff? Is our leadership actually doing a good job or have they made mistakes by hiring unnecessary people? Am I unnecessary? Are managers appeasing investors who care more about their return or even worried about their own bonuses? All of these thoughts swirl through my head and others’ heads as we move forward. I don’t want you to feel bad here, but to think about your situation as someone that might get laid off or survive one.

    Most of us don’t experience layoffs, and if we do, it’s not often that these happen. However, they are always possible, which is why I advocate for all of you to keep learning, regularly grow your skills, keep your resume up to date, and be aware of how your organization is operating. It’s good to work as if you’ll continue in this position (if you enjoy it), but my motto is: hope for the best, plan for the worst.

    Of course, if you don’t like your job, you should be working to find another one. The best time to find a new job is while you already have one.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Creating Documentation

    Who should create documentation for software? In many companies, it’s the developers. In fact, in Redgate, often our developers are tasked with updating articles for products on our documentation site. We do have a streamlined process that has developers can submitting changes in some format (markdown? ) and an automation process that automatically updates the site as part of a release.

    However, we also have marketing people who are in charge of external articles and communications. They ensure that our product learning and university content is updated. They work with technical people to produce, edit, and publish content. These could be developers, advocates such as Grant or Ryan, or even partners. Our Friends of Redgate also help with content.

    Who should write and update documentation? Developers might best know how software changes, especially for new features. I know that developers also hate this chore, and I think they often don’t have the best perspective because the documentation should explain how I use things, not how I built them or just how I expect them to work. Developers sometimes just want to document how they expect the software to work.

    At the same time, marketing or some other area might not be aware of changes, necessitating more handoffs from the development teams. That can be a bottleneck in a DevOps flow. Of course, some of this process could be automated, like sending release notes to marketing. However, there is also the need for someone technical to review changes, which can require more resources. It could also mean marketing people ask developers to review changes, taking up their time anyway. If developers are like me, then they might just want to handle it themselves than communicate changes and still have to review someone else’s writeup.

    There probably isn’t a hard and fast rule. Not everyone communicate the same, or even that well. Writing is a skill, and while I might ensure all developers work on this skill, I might also try to lean more on those people that communicate well to ensure docs are updated for our clients.

    If you are building internal software, perhaps you forgo documentation entirely. I could see developers having a meeting with either QA staff or perhaps a business person to teach them what is changing. Then this person gets tasked with training others on the software rather than ensuring any formal documentation exists. Tribal knowledge might be the best solution here.

    If you’re a developer, would you want to control documentation or avoid it like the plague? Let me know today in the comments.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • A Case for Document Storage

    One of the challenges for both database developers and administrators is doing more, often with less. Many companies continue to grow their database estate, both in width with more platforms, and in depth with more instances of the platforms they have.  Some companies will look to shrink their staff, especially when adopting a cloud platform, while others may add more databases, but not increase staffing to match the additional load.

    In either case, what many have found over the years is that the cost of labor is high. Both for developers that write code against databases, and administrators that manage those platforms. While licensing can seem to be a large number, compared to the cost of labor, it isn’t usually a significant number.

    Often it seems administrators would prefer more of the same database platform. Developers often seem to ask for new types of database platforms, often some type of NoSQL data store. I ran across an article that makes a case for adding in document storage data stores to your environment, instead of just choosing am RDBMS. Labor is one of the big reasons for doing this. The other one is that for a given workload, the hardware cost is lower.

    The article opens talking about the object/relational mapping problems. There is some truth to the time and effort to map an object in an application to a table (or set of tables) in an RDBMS. There is some knowledge required to do this, but I also think it’s an important skill for many developers. The same type of object mapping to a serialized JSON document is shown as being easier, and it is.

    However, if you add or change your object, the application code to handle the document from the data store gets complex. Over time, you will have lots of “new” fields that don’t exist in older documents. How do you handle those? It’s not hard, but labor is required to write this code. And this code has to be maintained over time.

    The other argument is that less hardware is needed, made by noting all the data you may need can be co-located with your object. This is what we would call denormalization in an RDBMS and leads to data duplication? Whether that is a problem or not depends on the amount of duplication. Certainly the structure of an application that often works to send or retrieve singleton rows is easier in a document database.

    However, non trivial queries, which the author postulates are hard to write for developers, are likely hard to run for a document database. The load of querying across lots of rows, or updating them, is much higher in a document database. Depending on how often you update data, this can be an issue, and require more hardware.

    Which is better? The classic “it depends” applies here. Database modeling is important in both cases. As I’ve worked with people that move to NoSQL databases, I find they struggle to model in that world as much as many of us struggle to model in the RDBMS world. I also find that a NoSQL database often is going to require some sort of data warehouse or other structure that is built for reporting across documents.

    I’m not against the various types of NoSQL databases, but I also don’t think they are a panacea of any sort that magically makes building and operating an application easier.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.