Mind Over Milkshake (Thoughts Matter)

  • Comments posted to this topic are about the item Mind Over Milkshake (Thoughts Matter)

  • Heh... it's funny... I see so many people saying that people who are resistant to change are stuck in a rut.  I guess it's never dawned on those people that the people they're talking about have tried many, many changes... and most of the changes sucked.  There's something missing from a capability or something takes more steps or clicks (Ribbon Bar was a great example of that).

    Maybe the people that are really stuck in a rut are the ones that are stuck in the rut of always having to change and never spending enough time to learn anything well enough to be able to identify that an upcoming change is going to absolutely suck.

    They also stuck in the rut of saying other people are stuck in a rut.

    As another article was titled... take your loss and get over it. 😉  Your new stuff isn't always better and, to be honest, is usually not better and is frequently much worse.

    --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)

  • Resistance to any change in systems, until they break beyond repair, is a bad practice. But I've seen this happen in the past and happening. I've done my best to try and encourage us to upgrade, at least some portions of software solutions, to no avail. After years of not being heard, until a system fails beyond repair, it leads to learned helplessness. In a way I think some of this may change, if we're required to adopt creating SBOMs for the software we write or use. Time will tell.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work wrote:

    Resistance to any change in systems, until they break beyond repair, is a bad practice.

    I strongly disagree... especially when someone claims that such a thing is a "practice", either good or bad.

    Like everything else, "It Depends".  And, contrary to popular belief, not everything that is static will "break beyond repair".  In fact, I've found that the more often something is changed, the more likely it is to break.  SQL Server is a perfect example of that with a basic train wreck that runs about 30% slower across the board for us in SQL Server 2022 than it did in 2016 or 2017... even on the very same machine and yeah... all the settings are correct, etc, etc, ad infinitum.

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

    --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)

  • I suspect SQL Server 2016 runs better than 2005.

     

    It's always an "it depends" discussion. Some things run for years, and there's no reason to change. Some things do need to change because they deteriorate. Learning to decide when change is needed and when it's not is a useful skill.

    I think far too many devs want to change because they want to change, or they're bored, or they see something shiny. Or maybe they believe marketing. I think Jeff sometimes avoids change just because, though I do see him query people about why they make a change and the benefits for some things (PoSh), which means we can have a rational discussion.

     

Viewing 5 posts - 1 through 4 (of 4 total)

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