Paying attention to detail and being thorough.

  • Why is it that the qualities of paying attention to detail and being thorough are missing from an alarming percentage of developers and DBAs that I work with?

    I have lost count of the number times I have averted disaster by doing a code review of every piece of SQL code that is pushed to production.

    Rant over...

  • When i started in this business it was a science , i still try to see it like that.

    Unfortunately that does not seem to be the case for some people entering the profession now.

    Quick results , and a flashy gui are what is needed (and demanded ) by management. To hell if the data is correct.

    Just be glad they dont build bridges and are only playing with software. 😉

    My rant off 😉



    Clear Sky SQL
    My Blog[/url]

  • It's real hard to come up with a more meaningful post on this subject than what the two of you have already so I'll leave my rant about this right where it is... at the bottom of this nice cold beer. 😛

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

  • I'm not so sure it's that bad. I like to think of myself as reasonable successful in this field and competent at my job. I would make the claim to being detail oriented, yet just today, I deployed scripts to the wrong database because I missed that little detail in the email from the developer. My bad, no way around it. The thing is, we're all human and no matter how detail-oriented, we're all going to miss stuff, especially if you take into account the different focus each of us has.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • I don't think things have changed at all, there have always been people who don't pay as much attention as they should and there's always been code that gets pushed out before it is ready. It has never really been a science. I don't know anyone who hasn't been inheriting bad code since the beginning of their career.

    Lack of attention to detail and precision is common in just about every job. There are a few who do pay attention and the vast majority who don't.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • I think Stefan has hit the crux. Most people don't pay attention, and as IT exploded in the 90s, more people of both types came to work here.

    I used to do code reviews of all code. In fact, all code we wrote had to go through 2 code reviews before it went to QA, and I think things were higher quality. Then came the web where we deployed much quicker, and I think the philosophy has changed. Get things done quickly, and we can fix them quickly. That, and hardware can mask issues in some systems.

    There does seem to be a faster pace, though I'm not sure building something well is done any quicker. We've moved some of our development time into the "bug fix" time instead. So the client gets something quicker, but it might not work right until the same amount of time has passed.

    Is that good or bad? In some ways I think it's good. IT does seem to get projects out quicker, and we get more feedback. That is good. It helps us hit closer to where the client wants things. Obsessing over too many details, tuning too early, can be wasted efforts since we know the client/customer often doesn't know what they want and can't even give us feedback until they see something. Then we can start to work on more details that are relevant.

  • I know of very few DBAs who are not detail oriented.

    Detail is part of the calling of the profession, and it calls each of us tightly wound, detail-oriented control freaks out of the woodwork 😛

    I think Steve nailed it on the head about the burden of "super tight code" being shifted to hardware. It's cheaper and that's where the burden "belongs" these days.

    I would add to the rant that I just don't see adequate testing done... especially scale/load testing.

    Cheers and happy Friday!

  • Dave Ballantyne (2/3/2010)


    When i started in this business it was a science , i still try to see it like that.

    Unfortunately that does not seem to be the case for some people entering the profession now.

    Quick results , and a flashy gui are what is needed (and demanded ) by management. To hell if the data is correct.

    Just be glad they dont build bridges and are only playing with software. 😉

    My rant off 😉

    Some would beg to differ here in the States with all the recent bridge failures.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • I like what Grant added. Many of us are working in trimmed down shops with plenty of responsibility and duties for three dbas each. Being detail oriented, you still miss things. Busy trying to keep up with workload, trying to not be the bottleneck, trying to help the projects succeed - sometimes something gets missed. I think a real big piece of the puzzle though is that when you do miss something - you have to fess up to it. No buck passing, put in the time to get it fixed - and move on.

    It is necessary to be detail oriented and involved in the beginning phases of any project. Requirements gathering and documentation need a lot of detail and attention. Doing those phases correctly will have a huge impact on whether the project is a success or not.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • I agree to some extent (actually to quite a great extent) with the first two posts, but I think they are missing a couple of points.

    First is the point that Grant made: no matter how careful we are or how much attention we pay to detail, we all make mistakes from time to time (show me a DBA or a programmer who has never made a mistake and you'll be showing me someone who has never done anything, I reckon) and that hasn't changed since the early days of computing.

    Second is a very different point: in the early days, everyone made mistakes but also everyone got it right most of the time. Over the decades I have seen more and more of a new kind of animal - the ones who hardly ever get it right, because they just can't be bothered to do any hard work, who are prepared to lie about how much testing they have done because they think they will get away with it. These are the ones whose activities make us feel as if almost everyone has stopped being careful and attentive to detail, but we shouldn't be blaming almost everyone, we should be finding these few(few? maybe 10 or 20 or 25 per cent) and making sure they are never in a position to wreck our projects.

    We'll never have a situation where everyone gets it right all the time, and we've never had one despite the nostalgia for the good old days: it just isn't human nature to have such a situation.

    But things have got worse, because a lazy and incompetent few can have an impact out of all proportion to their numbers, because idiotic development philosophies like the waterfall method dominate management thinking, and because management nearly always wants it done in less time than is needed to finish the job properly.

    Tom

  • Tom.Thomson (4/5/2010)


    who are prepared to lie about how much testing they have done because they think they will get away with it.

    Heh... I love it when they do that. Makes them easy to fire when their stuff repeatedly fails even though they've "tested it". 😉

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

  • Tom.Thomson (4/5/2010)


    show me a DBA or a programmer who has never made a mistake...

    I never make mistokes Tom :hehe:

  • Heh... me niether... 😛

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

  • Ho, eye mike meesteaks alll teh tmie

  • Jeff Moden (4/5/2010)


    Tom.Thomson (4/5/2010)


    who are prepared to lie about how much testing they have done because they think they will get away with it.

    Heh... I love it when they do that. Makes them easy to fire when their stuff repeatedly fails even though they've "tested it". 😉

    If the code is full of mistakes, what's to say the test plan or testing is free of mistakes?

    Maybe they are being honest in making that statement. 😀

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

Viewing 15 posts - 1 through 15 (of 20 total)

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