Voice of the DBA

Category: Editorial

  • Design Lessons for Software

    I play guitar as a hobby. Not great, but I enjoy it and find it relaxing. It’s a good break from my day periodically, killing a few minutes before a meeting. It’s also a nice way to unwind at night. I find it better than playing games or my phone or streaming more Netflix shows. I enjoy those as well, but there is something different about music.

    I tend to use acoustic guitars, meaning no electronics. However, I have had electric guitars in the past, and have even used pedals to alter sounds. When I saw this article about design lessons from guitar pedals, I was intrigued. It has 5 lessons from these devices, which are for other digital gear. However, I think they could apply to software as well.

    The first one is that these pedals are rugged. While I’m not stomping on pedals with my feed, I do think that we could ensure software is more robust and not susceptible to small mistakes by users, especially in the order of their touches/clicks that might cause problems.

    The second is about using more than our hands, which I hope doesn’t apply. You can add voice or gestures but don’t require those. I HATE those features. The fourth is about physical UIs, including physical buttons, which I think is important for cars, but not necessarily for all software. However, if you can give someone a button or knob instead of a touch, it can be helpful.

    The third is to have bold, visual cues. I had a designer once say we ought to build more Fisher-Price software, meaning something obvious and usable by a child. I know some of our processes are complex, but we ought to work to keep things as simple as we can. For databases, I think clear, consistent names help here, especially for indexes, FKs, and triggers.

    The last one is to make things beautiful. I have to admit I didn’t think about this much before coming to work for Redgate Software. Across the last 15 years, I’ve learned to appreciate the value of design, UX, and the people that make things look good. I can’t do that; I have no skill in this area, but I know that having someone come behind me to do this is worth the effort.

    Of course, on top of all this, your software has to work and perform well. If the software doesn’t work correctly or is very slow, none of your clients are happy. Learn to write better code, improve your skills, and listen carefully to those asking for features. If you do that, these design lessons will make sure all your efforts shine through.

    Steve Jones

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

  • 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.