Not exactly code review or source code control

  • If you can't clarify with the end user, the intermediary has to. If the intermediary won't, then you need to go up your own chain of command and back down the other end.

    The developer should never be assuming anything about what the end user wants on the way *out* of development. Oh, sure, you slap some pieces together for a Proof of Concept or a starting point for discussions with a user, but in the end the end users should be the ones deciding that your code did what they wanted it to. Not another developer during code reviews.

    Code reviews should help you nail down the idiosyncracies of a system, and make sure things will run clean (Cursor?! Explain this...) but should not end up as the final check on departure from development. Your end users should be doing that, and making sure that they're getting what they expected.

    In your case here, it sounds more like you had different end users signing off on different reports with different expectations. The question is: Is that a bad thing? In my mind, no. Two happy end users.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Good God I love this place!

    Thank you all so much for your time and ideas.

    Its given me a lot better appreciation of where the weaknesses are in our own processes.

    Some process is better than none, but as you've been so kind to show me, there's always room for improvement.

    best to you all and thank you again

    drew

Viewing 2 posts - 16 through 16 (of 16 total)

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