Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Examples needed of bad and good code pairs

Expand Messages
  • Lynn, James
    ... I actually believe you can not always
    Message 1 of 38 , May 30, 2000
    • 0 Attachment
      > >And as I have statement many times, there are many cases
      > where the actual
      > >use of a piece of code is unquantifiable because all you are doing is
      > >guessing at the inputs into the profile.
      >
      > I believe we both agree on this.
      >
      > Our first difference is in whether or not a profiling tool
      > can be used to
      > actually find the bottle necks in a system. You believe it
      > can not because
      > there is no way to know in advance what production data is
      > going to look
      > like.

      I actually believe you can not >always< rely on a profiler.

      > I believe it can because I am willing to wait to do
      > any optimization
      > until production data is available.

      And I have found that doing this is not always the best choice or possible
      for a custom solution. I have also found that when producing a product
      people are not very happy if they hit a certain amount of data and have to
      request an patch, especially (but not limited to) when they have probably
      bought the product from a revendor (as in a vendor that gets it from a
      vendor) and don't even know where to ask for an update and then just trash
      the product, which can be bad for something that is sold with a WOM
      marketing scheme.

      > Our second difference is in defining what is a lower risk
      > solution to a
      > problem. You believe we should always use the best algorithm
      > available to
      > us.

      Actually, I feel that using the best >well known< algorithm available is
      >often< the best choice but >that there are no hard rules< and that >the
      developer has to think for her/hiself<. There are even >rare< cases where
      you'll have to come up with a new algorithm. I agree that is can be a
      dangerous waste of time developing and implementing a new algorithm. But I
      also feel that there are cases where not doing so will violate DTSTTCPW,
      because you still have to fulfill the W part. so it is >the developers
      choice< if they think that the W is fulfilled and if they are nervous enough
      and profiling can't help, then the area warrants >thought and discussion<
      possibly even with the customer to let them know how long the implementation
      will take and what protection it will give them. But for a well known
      algorithm, there isn't much thought. Just find and take to code off the net.

      > The reason I work the way I do is based on two things.
      > First, as Kent has
      > shown us it is possible to defer changes to the system with
      > out increasing
      > the cost of making those changes.

      Only in certain contexts. There are more costs in releasing a faulty product
      than development time. This is true for your clients as well as your own
      shop. The installation of a patch can cost millions of dollars to your
      client. The damage to reputation can cost millions to you.

      James
    • Lynn, James
      ... I actually believe you can not always
      Message 38 of 38 , May 30, 2000
      • 0 Attachment
        > >And as I have statement many times, there are many cases
        > where the actual
        > >use of a piece of code is unquantifiable because all you are doing is
        > >guessing at the inputs into the profile.
        >
        > I believe we both agree on this.
        >
        > Our first difference is in whether or not a profiling tool
        > can be used to
        > actually find the bottle necks in a system. You believe it
        > can not because
        > there is no way to know in advance what production data is
        > going to look
        > like.

        I actually believe you can not >always< rely on a profiler.

        > I believe it can because I am willing to wait to do
        > any optimization
        > until production data is available.

        And I have found that doing this is not always the best choice or possible
        for a custom solution. I have also found that when producing a product
        people are not very happy if they hit a certain amount of data and have to
        request an patch, especially (but not limited to) when they have probably
        bought the product from a revendor (as in a vendor that gets it from a
        vendor) and don't even know where to ask for an update and then just trash
        the product, which can be bad for something that is sold with a WOM
        marketing scheme.

        > Our second difference is in defining what is a lower risk
        > solution to a
        > problem. You believe we should always use the best algorithm
        > available to
        > us.

        Actually, I feel that using the best >well known< algorithm available is
        >often< the best choice but >that there are no hard rules< and that >the
        developer has to think for her/hiself<. There are even >rare< cases where
        you'll have to come up with a new algorithm. I agree that is can be a
        dangerous waste of time developing and implementing a new algorithm. But I
        also feel that there are cases where not doing so will violate DTSTTCPW,
        because you still have to fulfill the W part. so it is >the developers
        choice< if they think that the W is fulfilled and if they are nervous enough
        and profiling can't help, then the area warrants >thought and discussion<
        possibly even with the customer to let them know how long the implementation
        will take and what protection it will give them. But for a well known
        algorithm, there isn't much thought. Just find and take to code off the net.

        > The reason I work the way I do is based on two things.
        > First, as Kent has
        > shown us it is possible to defer changes to the system with
        > out increasing
        > the cost of making those changes.

        Only in certain contexts. There are more costs in releasing a faulty product
        than development time. This is true for your clients as well as your own
        shop. The installation of a patch can cost millions of dollars to your
        client. The damage to reputation can cost millions to you.

        James
      Your message has been successfully submitted and would be delivered to recipients shortly.