Learn to Change

  • Comments posted to this topic are about the item Learn to Change

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • automate your backups! practice your restores!

     

  • Adapting to change is at the core of what most of us do on a daily basis. The only constant thing about my job is that everything changes, all the time. Good observations and nice editorial Mr. Fritchey.

  • I think it's actually a much more valuable skill to learn when to NOT change.  I've seen a lot of so called "improvements" to things, especially in the world of software, not actually be worth a hoot.  Features are lost.  Considerations for human factors go by the wayside.  It takes more clicks to get to the same menu.  Where you once had a nice full screen that took full advantage of the hardware you have, a lot (especially on websites) has been changed to "fit a phone" and 2/3rds of more of the screen is empty space.  Where you could once read everything you needed to on a single screen, you now have to scroll 3 or 4 (or more) pages down to get the same read because programmers will take the time to cookie you to death but they're apparently incapable of doing a simple presentation tweak.  I have to tell you that, at best, it seriously interferes with coffee in the morning and Scotch at night. 😉

    Another example is that CROSSTABs used to be covered in Books Online and were indexed quite nicely in Help.  There's still a listing for "Crosstab Query" in BOL but it takes you to PIVOT... which is frequently twice as slow.  I don't use PIVOT except to demonstrate how it compares to CROSSTABs.

    Although change is inevitable, change for the better is not and you have to have the nads to "just say no" to the latest software drug.  Of course, that will also mean that you might not be the "cool kid" on the playground anymore.  That's where having "the nads" comes in to play. 😉

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

  • Adaptability, I think is key to survival in this business.  But as Jeff said 'change for the better is not'.  And at my previous job I was labeled 'resisting change' when I spoke up on changes I didn't think were in our(IT's) best interest.  I didn't win that argument(not big enough nads I guess) ;-).   It could be one of the factors used to 'transition' me out of that company.  Worked out great for me, not so for the poor people left behind.  As I sit here typing this I've already been told I can leave for the day for the holiday, we are off on Tuesday and Wednesday.  It's a great company that understands the work will be here wen we get back. Sorry, I kind of got off topic there.

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • Change is change. Whether its better or not is something we have to evaluate, test, experiment with, and decide. I worry about people getting caught up in thinking we need to change or we need to not change.

    Often the best choice is situational.

  • Steve Jones - SSC Editor wrote:

    Change is change. Whether its better or not is something we have to evaluate, test, experiment with, and decide. I worry about people getting caught up in thinking we need to change or we need to not change.

    Often the best choice is situational.

    What I worry about is when change is actually for the worse as in often the only choice is damaging and there is no real choice.  So many people institutionalize change as being something that is absolutely necessary and that something is wrong if there isn't change.  There's also a whole lot of times when changes for the worse leave us no choice in the matter, something that Microsoft has recently gotten very good at.

    For example, Microsoft's "Fast Inserts" killed me.  This is where "they" decided to "help" people that may not know better and make it so that, rather than spend the time to check to see if any partially full extents are available to be populated during inserts, they decided that it would be better to just allocate full extents for every "insert bulk" (and similar but not to be confused with BULK INSERT)... even if it's just for one freakin' row!!!  That caused my WhatsUp Gold database to grow to well over 50GB even though there was only 8GB worth of data.  The rest was all "allocated but unused" and the only way to fix the wasted space is to rebuild then affected indexes.  Fortunately, they DO allow us to get around that by invoking Trace Flag 692 but most people don't realize the extra load placed on index maintenance because of it and, because their index maintenance "covers up the steamer", most people aren't even aware because it's not exactly well advertised (the problem found me and I had no inclination except for a random post that I wasn't even looking for and was getting ready to blame the vendor).  For ever increasing indexes, they might not realize it for quite a while.

    Then there's the double whammy of SET IDENTITY INSERT ON forcing a SORT in TempDB even during BULK OPERATIONs on empty tables when the source table is already sorted by a Clustered Index and the fact that they did the equivalent of PERMANENTLY invoking Trace Flag 1117 on TempDB with no option to temporarily disable it.  Imagine my surprise when I tried to copy a small 25GB table from one database to another causing my 8 file 100GB TempDB drive to fill up because each of the files insisted on growing to 25GB (25GB * 8 > 100GB) and blow a weekend project out of the water as a result.

    As you say, change is good if it's tested but it appears that Microsoft has virtually no practical experience in what people actually need to do.  All this automatic "improvement" coming up in 2019 scares the cannolies out of me.  The "It just runs faster" initiative has made it so that some of my stuff just doesn't run at all (it used to) and I'm left with coming up with panic work-arounds.

    So change is NOT change.  Sometimes it's a totally wasted and damaging effort that some of us have no choice in.  I'll say it again...

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

    ... and, especially lately, MS has not been good at it.  What's next?  Them putting data centers in glorified sewer pipes with end-caps and a bazillion sacrificial anodes on them and then putting them in the oceans to dissipate heat?  Funny I should ask...

    https://news.microsoft.com/features/under-the-sea-microsoft-tests-a-datacenter-thats-quick-to-deploy-could-provide-internet-connectivity-for-years/

    I'm sure that someday soon we'll be reading about how a foreign country built a submarine to steal the damned things out from under our noses.   If I had the money, I'd build a thief sub myself just to prove the point.  Who needs "ransomware"? 😀  Might not be enough time, though.  Those sacrificial anodes don't last as long as some may expect, especially if they're using the hull as a ground and it's not a single point ground attached to the hull.

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

Viewing 7 posts - 1 through 6 (of 6 total)

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