Category: Editorial

  • DevOps is DevOps

    DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

    That last one only comes if you use testing and try to ensure your code is well-written. It’s easy to just use DevOps to throw out more poorly written code that doesn’t perform well.

    Recently, I went to a presentation on Fabric CI/CD, looking to see if I could learn something about how you might handle Fabric in a DevOps software development flow. What I came away with was the idea that DevOps is really just DevOps. In this case, Azure DevOps was being used to orchestrate the CI/CD flow, and the pipeline looked the same way as one I had set up for a relational database.

    There are differences, such as the need to have multiple Fabric workspaces and a need to understand how the code is stored and managed in Git, but the idea is the same. We use a build step to verify that any code changes can be successfully compiled and that those changes can be deployed to a new location. A workspace instead of a database, which means the automation doing the work is slightly different, but the process is the same.

    Testing? You want tests to verify that the code does what is expected. A lot of people skip testing with data, but I’d argue it’s as important in Power BI or SQL Server as it is in C#. We ought to include tests, not because we don’t know how to write code, but because others might maintain/extend/refactor our code, and we want their changes to pass our tests. Again, the details are different, but including a step to run tests is still there. The same idea.

    Using a flow to approve and deploy changes between environments? This is no different, and having an automated process reduces the effort, time, and risk of mistakes. This is again the same, though the details are different specifics because the automation is different. Deploying a semantic model is different than pushing out a new .exe or running database changes, but the idea of an automated deployment is the same.

    We, as an industry, have learned over time how to better move code through a software development life cycle. The ideas work for data-based projects as well, and we ought to be learning and adapting these to ensure we can be just as agile as application software developers.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Can/Can’t Do/Don’t

    The other day, I asked my daughter if she wanted me to make her some eggs. She responded with a “Yes!” in text and came to sit up at the counter while I cooked for us both. We chatted a bit, and at one point she said, “Thanks for cooking, but it’s not that I can’t cook.”

    I laughed a bit and responded with “this isn’t a can/can’t situation, it’s a do/don’t or will/won’t one.” I know my girl can cook; I made sure all my kids learned how to cook. It’s that they often choose not to, hunting for leftovers, going for takeout, or skipping meals.

    I’ve never been one who likes to hear “can’t” from anyone. Even today, when I coach kids and one say “I can’t do that,” my response is “yet. You can’t yet.”

    It’s easy to think that because you don’t know how to do something, or don’t have confidence, or you’ve not done it well (or right) in the past, that you can’t do it now. That could be true, but often I find people default to “can’t” when they really mean they don’t want to do something or won’t do something. Easy to confuse those, and easy to brainwash yourself when using the wrong words too often.

    There are things I can’t do. For example, I can’t run a 10.0s 100m dash. I can’t dunk a basketball, though there was a time I could. However, on the ranch or at work, I rarely find that I can’t do something if I apply myself with a little curiosity, effort, and experimentation. I can learn most things and do them well enough to meet a goal. Someone else might do them better, but I can learndo them.

    I see too few people in the world who aren’t curious at work, aren’t willing to put in extra effort to get a task completed, or don’t feel an urge to tackle tasks outside of their comfort zone. I see fewer people dedicated to making an effort to learn outside of work time, whether on their own or at an event like a SQL Saturday.

    Most of the people I see succeed and thrive in jobs aren’t smarter than others. They just do the work. And if they don’t know something, they teach themselves what they need in order to get the job done. They drive themselves forward.

    Life is hard, but it gets easier when you want to put in effort to make it better.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Be Wary of Data

    I fly a lot, as you might have guessed if you read my blog regularly. In 2025, I’ve been on 56 United planes as I write this, with about 10 left to go before the end of the year. One of the things United does is sometimes send out a quick “survey” after a flight, checking to see if everything went smoothly. I don’t always fill these out, but recently I decided to give some feedback as I had a great experience.

    I really wanted to just complement the onboard crew, but the survey was quite a few pages (10?) and a lot of questions. I started to try and fill it out, but lost focus after a few pages. This felt like a chore, and I started to just randomly click some of the selections asking me to rate things 1-10. I wasn’t really rating the items; I was trying to get done. Eventually, I bailed on the survey and didn’t complete it, but that got me thinking about the data from these surveys.

    I’m somewhat detail-oriented and I try to do a good job, but I couldn’t finish the survey. How many others just click through things and don’t really give an accurate picture of their feelings?

    A similar situation occurs at work, where we have an HR rating system (Thymometrics), which I really like. Over time, it helps me to keep an eye on how I feel about my job, the company, and my general attitude about work. We get quarterly reminders to fill this out, but I know quite a few people who don’t fill it out at all, or just click on it and save the ratings without thinking about them. Another place data might be suspect.

    At work we get feedback on various product metrics, in addition to uninstall feedback and product feedback, sometimes with a rating that people click. Is that what they really think about their experience or did they just click the first thing they saw? Or did they mis-click the wrong thing, and they can’t change their rating (clicking 2 when they meant 9).

    There is a lot of data that organizations collect from people that is very subjective. Across a large group of users, this should provide some sort of indication of how people feel, but if the sample sizes are small, can you really use this data? I think it’s easy for people in product management, marketing, and sales to view this data as much more accurate than it might be. I know I’m always wary of any outliers when I see feedback, and often I want to know how many people contributed.

    Unless it’s a decently large number (100s at least) and there is a clear trend from many people (> 5%), I tend to discount the data as an outlier and not representative.

    I’m not sure how many of you do this, but critically examine data and be wary of drawing conclusions. Especially when you are getting impressions, feelings, and opinions from others.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Republish: Limiting the Ability to Concentrate and Collaborate

    It’s another Monday off for me, this time likely catching up on some fall maintenance before it gets really cold. Plus, I’m gone in the UK next week.

    While I’ve likely doing something with my hands, and concentrating outside, you get to read about doing that inside:  Limiting the Ability to Concentrate and Collaborate