Author: way0utwest

  • Building Quality In

    I heard someone at the 2020 DevOps Enterprise Summit conference say that quality needs to be built in. That’s something that many, or hopefully most, of us believe. Everyone ought to do quality work and build it into their daily tasks. However, the person speaking went further and defined this in a way I like:

    “Building quality in means we don’t pass quality issues along to others.”

    That’s a much better definition for me. This implies that there are effects if I don’t do a good enough job. If I knowingly pass along an issue, that’s a problem. I haven’t done quality work. I’d likely say that if I don’t bother to test or evaluate my work in some way, I’m essentially doing the same thing.

    We all write poor code, or do a job poorly at times. Often this comes because of ignorance, naivety, or just a lack of skill. That’s understandable, and we can forgive a person not being able or ready to do a job at the same level as a more experienced person.

    However, that should be a learning and teaching moment. We don’t expect continuous quality issues, certainly not of the same type. A big part of the DevOps movement, and other modern software development methodologies is learning from our mistakes. Getting better. Improving the quality of our software.

    Don’t just get work done. Don’t just close tickets or move a sticky note. Learn to do better each time you make a mistake. Learn to write better code or implement better processes. Learn to build in quality.

    Steve Jones

  • Daily Coping 29 Oct 2020

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, 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 be kind to yourself today. Remember progress takes time.

    This is something that having and working with kids has taught me. I’ve watched them take advice or coaching from me, or not, but I can see there is a difference across time.

    Lately I’ve had a lot of deliverables, for various different presentations. Rather than get upset or concerned when I’ve been delayed in getting something done, I’ve stopped and reminded myself that a task may just take time.

    It’s helpful to remind yourself that despite getting things done today, I may have more to do tomorrow. As along as I’m making progress, that’s OK.

  • Lean Coffee

    I read about the concept of Lean Coffee in Making Work Visible, one of the books I set as a goal to read this year. The idea is to have an agenda less meeting, but nevertheless get some things done.

    It sounds crazy, though the format makes some sense. The group takes a minute or two to write down some ideas on paper. Each person then gets two votes to place against the topics. The top rated items get discussed first for a period of time and at the end of that time, everyone votes on continuing discussion or moving on. This can repeat every few minutes.

    I got the chance to experience this at the recent DevOps Enterprise Summit conference, where there were Lean Coffee breaks every day, with each having a topic that people wanted to discuss. One I participated in was fairly rigid, with the facilitator keeping to time, gently encouraging discussion, and rigorously calling for votes.

    While I enjoyed that, a second one didn’t use timers consistently or votes, and the meeting ended up being a rather free form discussion, which was OK, but it meandered and wandered without guidance in a way was somewhat annoying. It was a surprising experience for me, as I typically like free form discussions.

    I don’t know that I’d recommend Lean Coffee for all meetings, but I do like the format, and I think this can be a good way to focus on a few areas a team finds important, especially when there isn’t a clear set of priorities.

    I would encourage you to give it a try, especially if you get into a meeting without a clear agenda. Maybe it’s something I’ll try as a way to discuss and debate some topics at some event.

    Steve Jones

  • Using Write-Debug

    I wrote a post about PoSh output recently, noting that in general we ought to use Write-Output or Write-Verbose for messaging. In there, I mentioned Write-Debug as well as a way of allowing the user to control debug information.

    Since I often find myself fumbling a bit with debugging scripts, I decided to give this a try and see how it works.

    First, let’s build a simple script. In this case, I’ll write a script that takes two parameters and determines which one is larger.

    $i = $args[0]
    $j = $args[1]
    Write-Debug("First Param:$i")
    Write-Debug("SecondParam:$j")
    if ($i -eq #null ) {   $i = 1
      Write-Debug("Setting first as a default to 1")
    }
    if ($j -eq #null ) {   $j = 1
      Write-Debug("Setting second as a default to 1")
    }
    if ($a -gt $b) {   Write-Output("The first parameter is larger")
    }
    elseif ($i -eq $j ) {   Write-Output("The parameters are equal.")
    }
    else {       Write-Output("The second parameter is larger")   }

    If I run this, I get what I expect. Here are a few executions.

    2020-10-19 13_02_38-debugtest.ps1 - Visual Studio Code

    Now, what if I’m unsure of what’s happening. For example, I forget the second parameter. How does my program know the first parameter is larger? I have some debug information in there, but it doesn’t appear. However, if I change the value of $DebugPreference, I see something.

    2020-10-19 13_05_07-debugtest.ps1 - Visual Studio Code

    The variable, $DebugPreference, controls how Write-Debug messages are processed. By default, this is set to SilentlyContinue. However, if I change this to Continue, all the messages appear. If I want, I can also set it to Stop or Inquire, allowing me to control the program differently.

    You can read more about preference variables here.

    This is a handy thing to use. I’ve often had a variable I set in programs, sometimes as a parameter, that allows me to show debug messages, but I often then need a series of IF statements inside code to check this and display debug information. Now, I can just include write-debug info in my code, and if the preference isn’t set, I don’t see them.

    I’ve seen this used in custom cmdlets from vendors, including Redgate, and it is nice to be able to access more information when something isn’t working, and have it suppressed by default.