Voice of the DBA

Category: Editorial

  • Reducing Debt and Increasing Security

    Many of us know that reducing financial debt in our lives leads to a bit more security in our minds. We are better able to cope with unexpected expenses when we have the ability to get credit or pay for something in cash. If you’ve ever had a major house repair, car calamity, or (hopefully not) medical issue, you know what I mean. At least in the US. That last one is less of an issue in many other countries.

    We know that our code has technical debt, and often we fight a battle with project managers and business people over whether we should spend time paying down that technical debt or developing new features. We certainly can do both, but often that’s not a choice we are given. If we do get the chance to reduce technical debt, it’s a tiny fraction of the time that is allocated to adding something new.

    There might be a better argument for reducing some technical debt: security. There’s an article that talks about the security risk posed by moving too fast and not ensuring there is rigorous security testing. This is a common problem in many companies that adopt some parts of DevOps, but forget that quickly deploying new code isn’t the only principle. We also need to learn from our mistakes and quickly correct them.

    I am a big fan of releasing often, especially for security purposes, but those releases need to build on each other with not only new code but refactored old code that doesn’t perform well or has a security issue. More importantly, we need to ensure when we find issues in code, that all developers are aware of the problem and don’t repeat the issue. We also need to update our testing to ensure that humans don’t continue to write code in a style that causes known issues. We want to avoid antipatterns in our code.

    This is less of a developer issue than a managerial one. The C-suite and all management that are involved in software need to prioritize security so that known issues are fixed quickly. This also should involve ensuring that technical debt is kept under control as a lot of this poorly written code increases the chances that a vulnerability is in the code. Either because the code isn’t well written or because developers avoid touching the code in the future.

    The best solutions, to me, involve DevOps. Make small changes, deploy them, instrument them, and learn if they work well. If not, fix them quickly. While this might end up delaying some features, ultimately it ensures that our software is in better shape, with a reduced risk of simple security mistakes upsetting our customers.

    Steve Jones

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

  • DevOps is Mostly About People

    I was giving a talk on DevOps recently and one of the questions from a person in the audience was how to get others to buy in. This person also had complaints that “DevOps” wouldn’t work because their boss wasn’t interested.

    I think these are great examples of things that many developers and managers don’t think about when they look to embrace DevOps. While there is no shortage of technical articles and videos on how to introduce automation or deliver features in a new way, what gets lost is the need for cultural change.

    DevOps is all about people. It’s about learning to trust each other and work together. It’s about adapting and changing how you write or deploy code to make the process smoother. It’s about sharing your knowledge with others and learning from them. It’s about being blameless and also accountable. It’s about support from management to improve the software and the process.

    It’s about people.

    The automation is cool and it’s a lot of what is easy to demo and explain. I show that because I don’t know the people involved in your environment and I can’t explain how you can get them to change how they work. Instead, we tend to focus on the tangible things that an individual can learn: the technology. Use version control, validate and test with CI, deploy consistently with release servers, and build packages that are versioned and reviewed. Those are the easy parts.

    The culture is what really matters, both in development teams, in conjunction with ops teams, and with support for management. There is no magic to software development and DevOps doesn’t bring any. All it helps you understand is that you need to be a team to build great software.

    Steve Jones

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

  • Look Beyond What You See

    One of the sales managers at Redgate Software posted an origin story about how he came to work at Redgate Software. It’s an interesting story, and while I don’t work in sales or have the same origin story, I don’t know that I could have seen the place I’m in now early in my career.

    When I saw the video, it made me think of this movie scene, where Rafiki asks us to look beyond what we see. I think this is a hard thing for many of us, especially when many of us have been leaning on our skills in the past. What we know and what we are good at doing has led us to this place. Picking a new direction, or thinking in a new way might be hard.

    For lots of us, we might be concerned about the cloud, and what we should learn or where this might lead us.  Azure or AWS? Some might be concerned about moving into management. Will I be good at it? Will it be a better career for me? Others can wonder about specific technologies. Power BI or Tableau?

    I wouldn’t recommend a specific thing for anyone without knowing more about their situation, but I do advise people to be open to opportunities, investigate and ask questions, and embrace possibilities. Look for what might be slightly out of focus or uncomfortable for you. Look beyond what you see and consider what you haven’t seen before.

    My origin story is getting an electrical engineering internship. Finding that the group needed help with Lotus 1-2-3 macros. Realizing I liked working with computers more than walking around a power plant and working with electricians to follow designs. I then realized that I didn’t love programming or network support, but I saw an opportunity in 1991 to work with SQL Server, and I took it. I looked far beyond what I had thought about as a teenager, as a college student, and even as a young person in my career. I embraced an opportunity to write an article and that led me to SQL Server Central and now Redgate Software.

    Think about the directions you could take in any situation and open your eyes to the possibilities. You might find an opportunity that changes your life.

    Steve Jones

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

  • What Do We Want to See in SQL Server?

    I like the feedback system that Microsoft built for SQL Server. This used to be the Connect system, but all the bug reports and feature requests are now at feedback.azure.com. That’s the place where you can send notes to Microsoft or vote on those that others have submitted.

    In case you are wondering if this makes a difference, it does. Years ago, there pushback for Service Packs from Microsoft, and after a lot of lobbying from myself and others, and a number of votes, Microsoft released more Service Packs for a few versions. They’ve also made a few other changes in the product, or fixed bugs when enough people vote. Not always, but it does happen at times.

    When this system was first released, I wondered if Microsoft would email a digest or some list of items that they had triaged of how the various items were rated. I could see this as a way customers might learn what others think is important, as well as what Microsoft sees as feasible. Maybe where would be some repeat voting that could influence the products’ direction.

    Recently I saw Brent Ozar posted the top 10 items by votes with a few comments. Of the items on this list, I found some interesting ones. I know STRING_SPLIT gets an ordinal in Azure and SQL Server 2022, so that’s one item that MS responded to. I see a few SSMS ones, which are always interesting to me. I’d hope that MS would include a dark theme and the (maybe) the debugger back in as many people request those features. I’m not sold on the debugger, and it wasn’t always stable for me, so I wouldn’t use it, but lots of people like the idea of a debugger. Maybe if it were limited to the dev edition?

    Microsoft looks at the feedback, but the feedback isn’t a vote in their mind. It’s a metric that helps them triage and decides when things are important enough to work on, assuming the effort isn’t extremely high. Working in a software company gives me a better appreciation for the decisions made on which features to include or not, especially given the long-term support effort for any features.

    It can feel hopeless when you vote for something and Microsoft doesn’t build it, but when enough people, especially big customers, want something, it gets built. If you look through the top items, a few have been added to SQL Server 2022. Personally, I want a FOR CSV along with a BULK EXPORT command. I appreciate some difficulties here and possible permission/security issues, but this would be very handy.

    What changes do you want today? Is the dark theme or the debugger at the top of your list or is there something else?

    Steve Jones

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