Voice of the DBA

Author: way0utwest

  • Teams That Ship

    These days there is pressure on many software development teams to ship software more often. With the growth of DevOps and the numerous stories about companies that update their applications regularly, more managers are putting pressure on their development teams to perform. This can be a challenge as the culture changes needed to alter the way we work and achieve frequent updates are difficult to achieve.

    I saw a post from an entrepenuer, Naval Ravikant, on building a team that will ship software. This is advice for a startup, which often has different goals, challenges, and structure than more mature teams. Certainly I’ve seen the way we’ve built software at a few employers change. Even at Redgate Software, what we do to build software wouldn’t the same as what we did as a small company with 10 people.

    As I read the list, I can imagine why some of this advice is there. The need to push forward and get software working and in front of customers is strong. Sales, marketing, and certainly the users of the application want to see things move forward, features added, bugs fixed, and a reason that someone will pay money for the software. This rapid pace requires some decentralization, some lack of control, and trust in your developers.

    However, at some point this isn’t the model that a more mature organization needs. While we do want people that get work done in small teams at Redgate, we’re also more mature. Allowing developers to work on whatever they want isn’t in our best interest, and it could mean some products wouldn’t get any attention. We also have somewhat large codebases, so a person per project isn’t ideal. In fact, we often get code done in groups.

    I think I might be more inclined to adapt some of these goals with a startup, and certainly in a PoC or early access/beta product. However, once clients are invested and paying, I think a little more coordination and collaboration is likely needed. Not a lot, but a little.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • T-SQL Tuesday #125 Unit Testing

    tsqltuesdayThis month T-SQL Tuesday is hosted by Hamish Watson, quarantined down in New Zealand. Like me, he has a ranch, and kids, so he has space to move around a bit.

    Hamish is a DevOps and testing advocate, just like me. His topic this month is to ask “So now that I have introduced unit testing – is it valuable for implementing with databases? “

    I think it’s a great topic, and here is my take.

    Database Unit Testing Documents

    My big take is that database unit testing best documents what you, as a developer, think your part of the database code should do. You expect these things:

    • The API a table will provide
    • The way a CASE statement decides what to return
    • The formulas you use for aggregation
    • The manipulation a function uses to return a value

    And more. Ultimately, we interpret a requirement, whether written down or told to us. We often may slightly mis-interpret what someone told us, or not think of certain cases. A test forces us to document the way we think our code behaves with certain data.

    This isn’t perfect, as we still may not account for certain cases of data, we may have bugs, or we may interpret things incorrectly. However, the test documents what we think. When there is an issue, we can go look at the test and verify this behavior is what is expected. Or we can add a new test (or enhance ours) to handle the case we didn’t expect.

    There are plenty of other reasons, but I believe that testing helps improve quality because it forces us to think, it documents our actions, and it helps ensure we don’t create regressions of code that already works.

  • Daily Coping 13 Apr 2020

    I’ve started to add a daily coping tip to the SQLServerCentral newsletter, which is helping me deal with the issues in the world. I’m adding my responses for each day here.

    Today’s tip is to learn something new or do something creative.

    I like being creative, and it’s a good outlet for me when I do something with my hands. My coping started this weekend, as I mocked up a few wood projects and started working on them.

    I was hoping to work on a new charger stand, but never got to it. Instead, I tackled a few more horse feeders, which have broken. Rather than rebuild them, I came up with some creative ways to repair pieces, add reinforcement, and get them working. I managed to get one repaired and two close to the house.

    I’ll continue on to try and distract myself a bit when the weather clears, as it’s been snowing for two days.

  • T-SQL Tuesday Live 14 Apr

    Last week was a bust, which was disappointing for me. I look forward to touching base with a few people and seeing friendly faces. Somehow the meeting had an error, which must have been an issue with me editing the recurring meeting to add a password, a Zoom change, or something else. My money’s on Steve making a mistake.

    In any case, I’d like to do this again this week. I created a new meeting and tested it from a VM with none of my credentials. It appeared to work, so my fingers are crossed.

    Details

    Date: 14 Apr 2020

    Time: 13:00MDT/15:00EDT/19:00UTC/20:00BST (1 hour)

    Meeting: https://redgate.zoom.us/j/420898102

    Password: Cast this as in int –  0x000E418E (you should get a number starting with 9 and ending with 6.

    Issues: DM me on Twitter @way0utwest