Effectiveness

  • Jeff Moden (11/7/2013)


    ..."Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    Absolutely, but in the context of the posts on this thread: doing it right does not necessarily equate to doing it all. Yes, what you deliver must be done right but you may have to choose to not deliver the complete (perfect) system in the first instance (no DB pun intended) in order to deliver when required.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • -----"I hope that you haven't interpreted anything I have said as this. Sometimes, through appropriate design, you can have areas that need further refinement, efficiency or enhancements whilst still producing quality. An example might be that you know that there are another half a dozen reports that are required to complete the systems but as long as they can be added seamlessly as part of an upgrade, that they data is captured from the start and the UI remains intuitive then you may have released a "good enough" version initially followed by a "complete system"."----

    I agree with you that some parts can wait to be completed as long as the customer understands and agrees. This assumes , as you point out, that data is captured, VALID, and not critical to functionality and business operation. It's better to have NO data than INCORRECT date on which decisions are made and money spent.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Having read the entire thread I think it boils down to a cautionary tale with these points.

    1) Good enough is often judged by people who are not qualified to make the judgment.

    2) Good enough is often the excuse that marketing uses to get sub-standard product out the door so they can say "look, see? We deliver on time!".

    3) The people who are in a position to judge "good enough" do not have the power to veto release.

    4) Programming is hard. -- Sales weasel

    The people who ask you for software want it on their desk in 15 minutes. They don't want to hear about how long 100,000+ lines of code takes to *test*, they don't have to bear the pain of bugs, so they *do* *not* *care*.

    And that's why "good enough" leads to HealthCare.gov type solutions. Sure, you can have bad developers who don't understand all the parts of the system and why certain approaches simply are unacceptable at scale. But that usually isn't the case because *somebody* on the team does know.

    And there *IS* such a thing as "good enough". But C-level folks who wouldn't know a loop from a set from a polish sausage should never be the ones to set the deadlines.

    And heaven help the developer who's ultimate boss is a politician...

  • A large scale website is like an interstate highway, especially when it's being construted at tax payer expense. Cool features are nice to have (just like rest stops and trees planted in the median), but not at the cost of reliability and budget constraints. At the end of the day, the end users don't care whether the website was constructed using HTLM5, JSON web services, or reusable templates. All the users will remember is how long they had to wait and wether or not the website bombed with an error when they clicked the 'submit' button.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (11/8/2013)


    A large scale website is like an interstate highway, especially when it's being construted at tax payer expense. Cool features are nice to have (just like rest stops and trees planted in the median), but not at the cost of reliability and budget constraints. At the end of the day, the end users don't care whether the website was constructed using HTLM5, JSON web services, or reusable templates. All the users will remember is how long they had to wait and wether or not the website bombed with an error when they clicked the 'submit' button.

    Perhaps a reasonable analogy as, certainly here in the UK, service areas are often added decades after and even planned ones often aren't open when the road opens for the first time.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Jeff Moden (11/7/2013)


    Nevyn (11/7/2013)


    Doing it right the first time is a great motto, but when this decision is to be made, that ship has often sailed.

    That's EXACTLY the problem I'm speaking of and it has become a rule rather than the exception. It usually stems from someone making some over-promised agreement which also means that the ship sailed long before the first delivery could be made.

    "Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    +1

  • roger.plowman (11/8/2013)


    And that's why "good enough" leads to HealthCare.gov type solutions. Sure, you can have bad developers who don't understand all the parts of the system and why certain approaches simply are unacceptable at scale. But that usually isn't the case because *somebody* on the team does know.

    Yes and no. Good enough also leads to solutions that work well in many situations, perhaps over the lifetime of the application.

    And there *IS* such a thing as "good enough". But C-level folks who wouldn't know a loop from a set from a polish sausage should never be the ones to set the deadlines.

    Indeed. However I'd say clients can often give you an idea of whether "good enough" is enough. Not always, and not as things may grow, but certainly for the deployment.

  • Jeff Moden (11/7/2013)


    "Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    What's "right"?

    Jeff, overall I agree that we should strive to write good code, and learn how to do things better so that we aren't introducing performance issues because we're lazy about what we do. Often it doesn't take longer to do it better the first time, if you have the knowledge.

    But there are certainly ways that you can get work done that work just fine and aren't the fastest/leastIO/etc solutions.

  • Steve Jones - SSC Editor (11/8/2013)


    Jeff Moden (11/7/2013)


    "Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    What's "right"?

    What is "right"? :blink: BWAAAA-HAAAAA-HAAAA-HAAAA!!!! You've just proven my point, Steve! I'm absolutely amazed that so many people in the business don't actually know what "right" is! If someone has to ask that question in the world of IT, perhaps they're in the wrong business to begin with. 😉

    Jeff, overall I agree that we should strive to write good code, and learn how to do things better so that we aren't introducing performance issues because we're lazy about what we do. Often it doesn't take longer to do it better the first time, if you have the knowledge.

    But there are certainly ways that you can get work done that work just fine and aren't the fastest/leastIO/etc solutions.

    I agree... I even agree that you don't have to use the "fastest/leastIO/etc solutions". Things do not need to be absolutely "optimal" or I wouldn't be using SQL Server to begin with:w00t:.

    But "good enough" frequently means that something simply works for 5 or 10 rows and they ship it and that ain't "right". 😉 "Good enough" frequently means that there was only time to test the "happy path" and not the "unhappy path" because some C-Level weenie on a golf course made an unqualified and unreasonable promise and that ain't "right". "Good enough" frequently means letting the ORM write the SQL without checking to see if the passed @Variables have an N' in front of the literal character assignment when the index is on a VARCHAR column and that ain't "right". "Good enough" frequently means writing a WHILE loop or some other form of RBAR because there's only a "small number of rows" that will supposedly never grow and that ain't "right".

    To summarize, "Good enough" frequently means "it ain't right" and that ain't "right". 😀

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

  • BWAAA-HAAAA!!!! I just saw one of the recent posts on the "Today's Random Word" thread. The word that was posted was "erroneous". Thanks to this thread, my first thought was "Good Enough To Ship". :-):-D:-P;-):w00t::hehe:

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

  • Gary Varga (11/8/2013)


    Jeff Moden (11/7/2013)


    ..."Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    Absolutely, but in the context of the posts on this thread: doing it right does not necessarily equate to doing it all. Yes, what you deliver must be done right but you may have to choose to not deliver the complete (perfect) system in the first instance (no DB pun intended) in order to deliver when required.

    I never said that "doing it right" is the same as "doing it all". 😉

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

  • Jeff Moden (11/9/2013)


    Gary Varga (11/8/2013)


    Jeff Moden (11/7/2013)


    ..."Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    Absolutely, but in the context of the posts on this thread: doing it right does not necessarily equate to doing it all. Yes, what you deliver must be done right but you may have to choose to not deliver the complete (perfect) system in the first instance (no DB pun intended) in order to deliver when required.

    I never said that "doing it right" is the same as "doing it all". 😉

    Agreed. Just like good enough doesn't necessarily mean ill thought out shortcuts 😉

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (11/9/2013)


    Jeff Moden (11/9/2013)


    Gary Varga (11/8/2013)


    Jeff Moden (11/7/2013)


    ..."Doing it right the first time" shouldn't be just a motto. It should be the best of all practices.

    Absolutely, but in the context of the posts on this thread: doing it right does not necessarily equate to doing it all. Yes, what you deliver must be done right but you may have to choose to not deliver the complete (perfect) system in the first instance (no DB pun intended) in order to deliver when required.

    I never said that "doing it right" is the same as "doing it all". 😉

    Agreed. Just like good enough doesn't necessarily mean ill thought out shortcuts 😉

    Actually, I'm thinking that it doesn't take any thought at all to arrive at some of the nightmares I've seen in code. Even "ill thought out shortcuts" still take some thought. Take a look at the following recent editorial and you see some prime examples of "ain't right" given by the same person that asked me "what's right" on this thread.

    http://www.sqlservercentral.com/articles/Editorial/104398/

    Here's a quote from that editorial that speaks to exactly what I'm talking about (the emphasis is mine).

    It's a scary thought, and [font="Arial Black"]given the poor security habits of so many developers[/font], it's possible that many companies might find themselves struggling to conduct businesses while under attack. It might not be any different than if conventional weapons were being used near our facilities.

    [font="Arial Black"]The state of coding by so many "developers" today is somewhat scary[/font]. It's not even old applications that are vulnerable to SQL Injection, but [font="Arial Black"]even new systems that have poor security practices being used [/font]that are vulnerable.

    In the same vein, the "state of coding by so many 'developers' today" is even more scary because if knowledge of the compilers they use, knowledge of databases, good coding practices, and concern for good product were gasoline, many of them wouldn't have enough to run a sugar-ant's minibike through a matchbox.

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

  • Jeff Moden (11/8/2013)


    But "good enough" frequently means that something simply works for 5 or 10 rows and they ship it and that ain't "right". 😉 "Good enough" frequently means that there was only time to test the "happy path" and not the "unhappy path" because some C-Level weenie on a golf course made an unqualified and unreasonable promise and that ain't "right". "Good enough" frequently means letting the ORM write the SQL without checking to see if the passed @Variables have an N' in front of the literal character assignment when the index is on a VARCHAR column and that ain't "right". "Good enough" frequently means writing a WHILE loop or some other form of RBAR because there's only a "small number of rows" that will supposedly never grow and that ain't "right".

    To summarize, "Good enough" frequently means "it ain't right" and that ain't "right". 😀

    I'd argue that some of the places I've worked that's not the definition of "good enough". It is for some, but for others, those items aren't "good enough".

  • Steve Jones - SSC Editor (11/9/2013)


    Jeff Moden (11/8/2013)


    But "good enough" frequently means that something simply works for 5 or 10 rows and they ship it and that ain't "right". 😉 "Good enough" frequently means that there was only time to test the "happy path" and not the "unhappy path" because some C-Level weenie on a golf course made an unqualified and unreasonable promise and that ain't "right". "Good enough" frequently means letting the ORM write the SQL without checking to see if the passed @Variables have an N' in front of the literal character assignment when the index is on a VARCHAR column and that ain't "right". "Good enough" frequently means writing a WHILE loop or some other form of RBAR because there's only a "small number of rows" that will supposedly never grow and that ain't "right".

    To summarize, "Good enough" frequently means "it ain't right" and that ain't "right". 😀

    I'd argue that some of the places I've worked that's not the definition of "good enough". It is for some, but for others, those items aren't "good enough".

    I absolutely agree but you asked "what's right". I can't tell you that for any or every given company but I can tell you what "ain't right". 😉

    --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 15 posts - 46 through 60 (of 82 total)

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