The Old Way or the New Way

  • Comments posted to this topic are about the item The Old Way or the New Way


  • A couple of colleagues and I have been pushing automated data testing and deployment testing techniques and local workstation builds.  We've been equally amazed and dismayed at the lack of enthusiasm for changing to this approach.

    We've burned a lot of effort making it possible to

    • Build a local workstation by executing a batch/shell script.
    • Execute a one line command to deploy/rollback a release locally
    • Execute a one line command to test the release locally

    We've put together "....for Dummies" documentation to support these new methods.  We've hyperlinked between our Confluence and git README.md files

    We've "eaten our own dog food" and found it delicious.  Really a lot of it is the stuff that SQL Server folk and in particular Redgate tool users take for granted.

    A lot of hand holding has taken place.  We've tested our HOW TO documentation to new employees with a mandate for them to improve it if they can.

    We've invested time and effort to find out why there is resistance.  Bar one or two easily addressed niggles it really does boil down to "we like the way we currently operate".

     

    One of the points in the article calls out the effort to change vs the benefit to change.  In my experience the effort/cost are upfront and  highly visible.  The benefits are a promise that is to be delivered but not delivered yet.  Over time the ROI will be significant.

    I am mindful that Jeff Moden says "Change is inevitable, change for the better is not".

  • I've seen this behavior too, as I'm sure we all have. Steve, you point about team work is interesting. It's likely to come up today. As a developer I use Visual Studio. Visual Studio 2019 introduced a new feature called Live Share. Microsoft has back filled that into the older Visual Studio 2017, and it is also in Visual Studio Code as an extension. Basically, Live Share makes it possible for developers to collaborate on some source code. One will invite another to participate in reviewing some code together. Both can edit the code, at the same time. I think this is a cool feature, but I've never had a chance to use it, because I don't work on a team that practices code reviews. (As an aside, I've never worked on a team that practices code reviews.) Today, I think my boss will have two of us demonstrate it. I'll see how it goes. I'm hoping my teammates will see the value to Live Share, but they might just be too comfortable in not letting anyone else look at their code, that they'll just blow it off.

    • This reply was modified 4 years, 2 months ago by  Doctor Who 2.

    Rod

  • I study personality theory. I am pretty sure that a person's comfort with change can be described as a function of his or her personality type. I suspect anybody posting in this forum probably has a personality type that makes us extremely comfortable with change, so comfortable that we enjoy it. It is useful to note that most personality types are not nearly so comfortable with change as we are. In fact, many actively fear change. For us, with our extreme comfort with change, our role with others should be to help and encourage.

    Steve, I really like your 20% rule of thumb, it is very useful and reasonable. There is another rule, and that is that technology solutions deteriorate over time. They are constantly either becoming obsolete or being upgraded. Part of my job is encouraging users to move to newer technologies and solutions because otherwise they will wither and die.

  • I just finished reading Mike Cisneros, "the old way is better" blog post. It reminded me of an experience I had back in the late 90's, coincidentally working for the same state department I'm working again for now. At the time I was working in the state's labs that perform tests of biological samples, water samples, and other environmental items. At that time there was an instrument that was used for testing samples, that printed results on thermal paper. The problem was those instruments were old and the only company that manufactured the thermal paper had gone out of business, with no other company taking over. At the time I argued that we could write an application to do the same as the one written for those old instruments, but print to newer printers. It seemed very reasonable to me and within our technical skills. But rather than pursue that management opted to purchase all remaining supplies of the thermal paper. They basically punted the can as far into the future as possible, delaying the ultimate panic they eventually faced.

    Even to this day I couldn't believe the tenacious resistance to do nothing.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Doctor Who 2 wrote:

    I've seen this behavior too, as I'm sure we all have. Steve, you point about team work is interesting. It's likely to come up today. As a developer I use Visual Studio. Visual Studio 2019 introduced a new feature called Live Share. Microsoft has back filled that into the older Visual Studio 2017, and it is also in Visual Studio Code as an extension. Basically, Live Share makes it possible for developers to collaborate on some source code. One will invite another to participate in reviewing some code together. Both can edit the code, at the same time. I think this is a cool feature, but I've never had a chance to use it, because I don't work on a team that practices code reviews. (As an aside, I've never worked on a team that practices code reviews.) Today, I think my boss will have two of us demonstrate it. I'll see how it goes. I'm hoping my teammates will see the value to Live Share, but they might just be too comfortable in not letting anyone else look at their code, that they'll just blow it off.

    It likely will be hard. I remember when Redgate did some pair/mob programming years ago. People hated it. However, leads pushed it and over time, it took off. We tend to work in groups often, and solve problems together. This takes some getting used to. I'd push them to try this every day or two for an hour and get used to it.

    Ultimately, others will see their code at some point, especially if they support it.

  • For me, it's not a matter of being resistant to change or something new.  My problem is that I've seen all manner of supposed "improvement" and supposed "better ways to do things" and "better software for the task", etc, etc, ad infinitum and they simply have NOT been an improvement or better in any way, shape, or form.  In fact, they're, more frequently than not, a worse way and with less functionality.  The problem is that when you adopt someone's pipe dream, you're pretty much stuck with it until the next pipe dream because no one ever goes back to doing it right.

    It's also very difficult to tell what's going to be good or bad because the powers that be are in the "Keep of with the Jones" mode without having any demonstrable proof that their newest pet migration is actually going to do what's needed.

    "Change is inevitable... change for the better  is not".

    This is also where the old folks saying of "Old people aren't hard of hearing... we're tired of listening" to all manner of people's wishful thinking.  People forget how much change truly costs and, if there's little in the form of ROI, it'll keep costing even after the change is adopted.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Steve Jones - SSC Editor wrote:

    Doctor Who 2 wrote:

    I've seen this behavior too, as I'm sure we all have. Steve, you point about team work is interesting. It's likely to come up today. As a developer I use Visual Studio. Visual Studio 2019 introduced a new feature called Live Share. Microsoft has back filled that into the older Visual Studio 2017, and it is also in Visual Studio Code as an extension. Basically, Live Share makes it possible for developers to collaborate on some source code. One will invite another to participate in reviewing some code together. Both can edit the code, at the same time. I think this is a cool feature, but I've never had a chance to use it, because I don't work on a team that practices code reviews. (As an aside, I've never worked on a team that practices code reviews.) Today, I think my boss will have two of us demonstrate it. I'll see how it goes. I'm hoping my teammates will see the value to Live Share, but they might just be too comfortable in not letting anyone else look at their code, that they'll just blow it off.

    It likely will be hard. I remember when Redgate did some pair/mob programming years ago. People hated it. However, leads pushed it and over time, it took off. We tend to work in groups often, and solve problems together. This takes some getting used to. I'd push them to try this every day or two for an hour and get used to it.

    Ultimately, others will see their code at some point, especially if they support it.

    I was right that I'll start working with a colleague I've not worked with before. (I'm covering for another colleague whose had a birth in his family.) And we're going to try to use Visual Studio's Live Share. I think my colleague is more open than others on my team to change, so I'm hoping this will go well. It's a code base I'm not familiar with, so there's a lot I need to come up to speed on. I'll let him drive the Live Share - might go better that way. We just got introduced to work together on this project, before we both had to go off to different meetings related to COVID.

    Rod

  • GeorgeCopeland wrote:

    I study personality theory. I am pretty sure that a person's comfort with change can be described as a function of his or her personality type. I suspect anybody posting in this forum probably has a personality type that makes us extremely comfortable with change, so comfortable that we enjoy it. It is useful to note that most personality types are not nearly so comfortable with change as we are. In fact, many actively fear change. For us, with our extreme comfort with change, our role with others should be to help and encourage.

    Steve, I really like your 20% rule of thumb, it is very useful and reasonable. There is another rule, and that is that technology solutions deteriorate over time. They are constantly either becoming obsolete or being upgraded. Part of my job is encouraging users to move to newer technologies and solutions because otherwise they will wither and die.

    Very interesting, George! I confess that I thought all people had an equal resistance to change.

    Rod

  • GeorgeCopeland wrote:

    I suspect anybody posting in this forum probably has a personality type that makes us extremely comfortable with change, so comfortable that we enjoy it.

    In my case I like to see that the change represents a significant improvement or addresses a pain point. As an ex-DBA I'm quite risk averse and as an Aspie I'm a creature of habit.

    I like to see my work being useful to someone.  If I'm doing software development that means getting it delivered to a production environment and staying there.  Things like automated testing mean I can deliver more, faster and of higher quality in order to get my fix.

    Some change is touted as an improvement but in reality is just different. Some change benefits someone but disadvantages another.

    Being able to run a comprehensive suite of tests in seconds on my local workstation is a major game changer for me. It has let me deliver orders of magnitude more.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply