• Pingback: SQL Server Performance Tuning Politics | John Sansom - SQL Server DBA in the UK

  • Pingback: 10 Character Traits of Outstanding DBA’s | John Sansom - SQL Server DBA in the UK

  • S.E.

    Well, what I did recently in theme response is the following (not quite like you have recommended):

    I had the SP that was (among others) the cause for excessive blocking. The developers rewrote it so it became better (say, initial state was 1 on a 1-10 scale, the modified solution was about 4).
    I analyzed the SP logical block by logical block (there were only 4) and at the end of my mail I proposed a brand new solution which would have no cursors at all, and I proposed a new – covering – index to avoid the table scan.
    I was not unfriendly, nor friendly. I was objective.

    The reposonse was: “you’re right, that SP would be faster with your recommendations, but at this time we are working on rewriting some other SPs that are more frequently used. The SP you analyzed had en execution time of 200ms and it runs only a few times a day”.
    Well, they may be right, but that few times when it ran, in the problematic timeframe it ran not for 200ms but for 576 secs (due to blocking).

    At this point I got angry and replied: “OK, do what you think you must do, I’ll moderate myself with my
    recommendations. Let’s go!”

    Maybe I was wrong.

    What do you think?

    • http://www.johnsansom.com John Sansom

      Providing feedback can be a tricky task as you have seen. Your efforts are without a doubt well intentioned but unfortunately feedback is not always viewed or received in this way, and is something that you can not necessarily control nor should seek to.

      What would be a tragedy now is if you were to withdraw and to cease your efforts as a result of this single experience. Providing feedback is as much an art as it is a skill that you can develop and one that we are all developing continually. Sure there are guidelines you can follow but the connection you have with a particular individual is unique and in turn so too is each experience.

      Consider that ultimately you are not doing this for the benefit of your developers but for the benefit of your customers. Sure there can be benefits for those other than your customers but only if they are open to receiving these gifts.

      Thanks for your comments!

  • http://michaeljswart.com Michael J Swart

    I’ve been in that situation too. And I hear you loud and clear. If I listed my top ten frustrations for the year, then unimplemented recommendations would leave them all behind.

    The best I can do is make sure the business maker understands the risk. And at last resort – get them to repeat back to me. “I am choosing deadlines over quality”. I do it tactfully and it’s not always black and white. And I’m lucky that I got co-worker’s that trust me.

    But it sounds like you have people that actually don’t believe you. (Whether it ‘s personal or they’re hiding their heads in the sand) That’s the worst and I wish you luck. I’d shy away from snarky emails, but I don’t have any alternative.

    I am curious about what others think.

    • http://www.johnsansom.com John Sansom

      Some great advice there Michael, thanks for sharing!

      I too can say that I have learnt the email lesson the hard way from experience over time. Seriously people, if in doubt don’t send it out! :-)

      Extending what you touched on regarding emails, my advice to all is that in the event you find yourself heating up then move on to a different task, go grab a coffee, or step away from your desk for 5 minutes. Things “always” look different with a clear head.

  • http://sqlsolace.blogspot.com r5d4

    Have been there too. More recently than I would like.
    A developer I’ve been working with has ignored everything I’ve explained about sql server.

    As a result >

    1) We still have a ton of adhoc sql (stored procs, user defined functions etc are ‘too much work’)

    2) We have little Normalization (the clue is in RELATIONAL database). It is too much effort apparently, meaning –
    a) We have lots of duplicated data.
    b) A lot of it is large text data (meaning the data cache has NO chance and the page life expectancy is very low).
    c) Reporting on the data is painful.

    3) H/A technologies are near impossible. Try implementing replication and a reporting environment when your schema gets repeatedly ‘tweaked’…

    The individual always listens, but then does exactly the opposite.

    The most recent example is implementing Linked Servers for retrieving large results set and putting the code live (against my advice)

    Due to small company politics and the individual’s seniority (8 years loyal service), they frequently ‘work on live’ and retrospectively update dev & uat with db changes.

    My auditing skills have improved no end and I have automated checks of object changes to see ‘ what ‘x’ has done today ‘.

    It’s not a nice way to work though, and is very stressful.

    • http://www.johnsansom.com John Sansom

      Sorry for delayed response, your comment got caught up in the automated spam filter :-)

      You’re right, that’s not a nice way to work. How do you plan to move forward?

      • http://sqlsolace.blogspot.com r5d4

        I’m moving forward with my feet. right out of there.
        In a few days in fact :)
        r

        • http://www.johnsansom.com John Sansom

          Excellent news my friend!

  • http://kmescha.wordpress.com/ Keith Mescha

    Nice job on this, very good advice and something that I see happening on a regular basis. Sharing with the team here as I think your approach to sharing advice is great.

    Keep up the good work.

    • http://www.johnsansom.com John Sansom

      Thanks for the great feedback Keith, I really appreciate it!