• Barkingdog (1/26/2014)


    These changes were unexpected and only completed about 2 days before "review meeting 2"...

    I guess I understand their outrage, then. I could be wrong but I've always understood that Design Review Meetings were supposed to happen before new changes and to discuss the status of previous changes. When the problem(s) were first discovered, it would have been prudent to have an urgent unscheduled Design Review Meeting. Yep... that's going look like it's going to slow things down a bit but, in the long run, it will grease the skids for a smooth load because the whole team has been informed. Yeah... QA is a part of the team that Design and Development is on. Everyone has to remember that they're all working for the same company.

    To coin a parable, if someone lifts the log from just one end, the other end will still be on the ground and it'll be a real drag (sorry about the pun) to move it to where it needs to be in a timely fashion. Sure, it'll look like work is being done immediately but it would be much more effective and timely to get the team together, explain the plan, maybe take a couple of suggestions on the best way to lift this particular log and what path to follow to the destination, get everyone into position, and then call out "Readyyyyyy! 1... 2... 3.... LIFT!".

    As a similie, it'll also keep the log from getting so dirty and it might help keep from dropping the log because everyone knows which way to walk with the log. 😉

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