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

Re: [agileDatabases] Re: The Discipline of Agile

Expand Messages
  • Curt Sampson
    ... Not necessarially. The cost may at times be cheaper if you refactor at the end of a story because you re quite familiar with that bit of code. But if
    Message 1 of 17 , Feb 22, 2008
    • 0 Attachment
      On 2007-10-22 05:35 -0000 (Mon), Matt wrote:

      > I think when I was talking about refactoring in this post I was
      > referring to the refactoring of "bad code" which I think we both agree
      > should be done at the end of a story.

      Not necessarially. The cost may at times be cheaper if you refactor at
      the end of a story because you're quite familiar with that bit of code.
      But if you're not sure yet how to redesign things, or you think you may
      not be touching the code again before other changes make it irrelevant,
      it may be best to leave the refactoring for later, should you ever need
      to do it at all.

      As with many decisions that require an expert, it's not something for
      which you can just follow a general rule.

      > When I stated that the "code should always be ready for a new
      > feature" I wasn't intending to imply that the code should be ready
      > for the NEXT feature but rather should be decoupled and cohesive
      > enough to be ready for whatever requirements may come down the pipe.

      I agree with that, with the caveat that the level of "readyness" will
      change depending on the current stage of the project, anticipated future
      change, and so on.

      > > [1] http://www.amazon.com/Novice-Expert-Excellence-Clinical-
      > Commemorative/dp/0130325228/
      >
      > I may still read these books, although they are both older books so
      > they may not make it on the reading list.

      Well, I can't recommend _From Novice to Expert_ highly enough; even more
      than a year after I've read it, I'm still constantly drawing insights
      from it.

      > I have a hunch that what was holding you back a few years ago was not
      > that you "needed" rules but that you were trying to identify WHICH
      > rule was applicable in a given situation.

      Well, just to make my (and the above book's) point clear: you are not
      an expert if you are deciding which rule to apply. Experts don't use
      rules to make their decision, though they make go back afterwards and
      use rules to try to justify the decision to others.

      > The Dreyfus model does not necessarily imply a higher level of quality
      > in the decision making but rather a different process. Undoubtedly
      > Benner's work revolved around the ability to *quickly* make good
      > decisions under pressure (say a nurse in an ER.) But even though being
      > an expert might enable you to make decisions faster than a proficient
      > person who relies on rules, if those rules are of sufficient quality,
      > the quality of the decisions themselves will be similar.

      Well, as an expert in refactoring, I have to disagree. Of course I know
      lots of rules, but as mentioned above, I don't use them or even think
      about them I'm contemplating how to refactor something. I just look at
      the situation and the various forces involved, and do the right thing.
      It often violates some rules, because that's what I need to do to get
      where I need to go.

      This applies in other fields, too; take a look at computer chess for
      example. It took a several-million-times increase in computer power and
      decades of research before it became possible to build a computer that
      could defeat the best human expert players, or even good ones. If it
      were so easy just to work from complex rule sets, computers could have
      achieved this much earlier.

      And even in software development, being able to work quickly is
      important. Increasing productivity is the same as developing equivalant
      functionality faster, right?

      cjs
      --
      Curt Sampson <cjs@...> +81 90 7737 2974
      Mobile sites and software consulting: http://www.starling-software.com
    • Willem Bogaerts
      (sorry for the late reaction, yahoo groups settings kept fighting me.) ... Or the other way around: If the code is beyond understanding, you ll have to
      Message 2 of 17 , Mar 3, 2008
      • 0 Attachment
        (sorry for the late reaction, yahoo groups settings kept fighting me.)

        >> I think when I was talking about refactoring in this post I was
        >> referring to the refactoring of "bad code" which I think we both
        >> agree should be done at the end of a story.
        >
        > Not necessarily. The cost may at times be cheaper if you refactor at
        > the end of a story because you're quite familiar with that bit of
        > code. But if you're not sure yet how to redesign things, or you think
        > you may not be touching the code again before other changes make it
        > irrelevant, it may be best to leave the refactoring for later, should
        > you ever need to do it at all.

        Or the other way around: If the code is beyond understanding, you'll
        have to refactor to understand. That is usually only necessary with
        untested legacy code, but sometimes you have to.

        >> The Dreyfus model does not necessarily imply a higher level of
        >> quality in the decision making but rather a different process.
        >> Undoubtedly Benner's work revolved around the ability to *quickly*
        >> make good decisions under pressure (say a nurse in an ER.) But even
        >> though being an expert might enable you to make decisions faster than
        >> a proficient person who relies on rules, if those rules are of
        >> sufficient quality, the quality of the decisions themselves will be
        >> similar.
        >
        > Well, as an expert in refactoring, I have to disagree. Of course I
        > know lots of rules, but as mentioned above, I don't use them or even
        > think about them I'm contemplating how to refactor something. I just
        > look at the situation and the various forces involved, and do the
        > right thing. It often violates some rules, because that's what I need
        > to do to get where I need to go.

        Rules can be bent and interpreted. Experiences (the base of an expert)
        already are interpreted and are much deeper. As we are in a databases
        group, let's take the rule "Never use a field with a meaning as a
        primary key"

        I burnt my fingers well before someone told me that rule AND had my
        situation to explain WHY that rule existed. Still, lots of database guys
        will happily start a flame war if you mention that rule. One of those
        guys even enlightened me with a valuable insight, saying that "A primary
        key is just a unique key".

        When I started to think about a reply, it occurred to me that a primary
        key was just not a unique key, but a key unique across its entire
        lifetime. I think it is such an insight rather than the knowledge of a
        rule that makes an expert.

        Best regards,
        --
        Willem Bogaerts

        Applicatiesmid
        Kratz B.V.
        http://www.kratz.nl/
      • Andrew Gregovich
        Primary keys are not just unique keys, the basic rule is that they never (ever!) change. There s nothing though which prevents them from conveying meaning per
        Message 3 of 17 , Mar 3, 2008
        • 0 Attachment
          Primary keys are not just unique keys, the basic rule is that they never (ever!) change. There's nothing though which prevents them from conveying meaning per so. See http://en.wikipedia.org/wiki/Primary_key

          Due to the popularity of surrogate primary keys, many developers and
          in some cases even theoreticians have come to regard surrogate primary
          keys as an inalienable part of the relational data model. This is
          largely due to a migration of principles from the Object-Oriented
          Programming model to the relational model, creating the hybrid
          object-relational model. In the ORM, these additional restrictions are
          placed on primary keys:
          Primary keys should be immutable, that is, not change until the record is destroyed.Primary keys should be anonymous integer or numeric identifiers.For example, I quite often end up creating PKs with compound candidate keys which include timestamps. Having auto-sequences on every single tables sometimes has no benefit (both in terms of pure logic and performance).

          Regards

          Andrew
          ----- Original Message ----
          From: Willem Bogaerts <w-p@...>
          To: agileDatabases@yahoogroups.com
          Sent: Monday, March 3, 2008 7:49:38 PM
          Subject: Re: [agileDatabases] Re: The Discipline of Agile

          (sorry for the late reaction, yahoo groups settings kept fighting me.)

          >> I think when I was talking about refactoring in this post I was
          >> referring to the refactoring of "bad code" which I think we both
          >> agree should be done at the end of a story.
          >
          > Not necessarily. The cost may at times be cheaper if you refactor at
          > the end of a story because you're quite familiar with that bit of
          > code. But if you're not sure yet how to redesign things, or you think
          > you may not be touching the code again before other changes make it
          > irrelevant, it may be best to leave the refactoring for later, should
          > you ever need to do it at all.

          Or the other way around: If the code is beyond understanding, you'll
          have to refactor to understand. That is usually only necessary with
          untested legacy code, but sometimes you have to.

          >> The Dreyfus model does not necessarily imply a higher level of
          >> quality in the decision making but rather a different process.
          >> Undoubtedly Benner's work revolved around the ability to *quickly*
          >> make good decisions under pressure (say a nurse in an ER.) But even
          >> though being an expert might enable you to make decisions faster than
          >> a proficient person who relies on rules, if those rules are of
          >> sufficient quality, the quality of the decisions themselves will be
          >> similar.
          >
          > Well, as an expert in refactoring, I have to disagree. Of course I
          > know lots of rules, but as mentioned above, I don't use them or even
          > think about them I'm contemplating how to refactor something. I just
          > look at the situation and the various forces involved, and do the
          > right thing. It often violates some rules, because that's what I need
          > to do to get where I need to go.

          Rules can be bent and interpreted. Experiences (the base of an expert)
          already are interpreted and are much deeper. As we are in a databases
          group, let's take the rule "Never use a field with a meaning as a
          primary key"

          I burnt my fingers well before someone told me that rule AND had my
          situation to explain WHY that rule existed. Still, lots of database guys
          will happily start a flame war if you mention that rule. One of those
          guys even enlightened me with a valuable insight, saying that "A primary
          key is just a unique key".

          When I started to think about a reply, it occurred to me that a primary
          key was just not a unique key, but a key unique across its entire
          lifetime. I think it is such an insight rather than the knowledge of a
          rule that makes an expert.

          Best regards,
          --
          Willem Bogaerts

          Applicatiesmid
          Kratz B.V.
          http://www.kratz nl/



          <!--

          #ygrp-mkp{
          border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;}
          #ygrp-mkp hr{
          border:1px solid #d8d8d8;}
          #ygrp-mkp #hd{
          color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;}
          #ygrp-mkp #ads{
          margin-bottom:10px;}
          #ygrp-mkp .ad{
          padding:0 0;}
          #ygrp-mkp .ad a{
          color:#0000ff;text-decoration:none;}
          -->

          <!--

          #ygrp-sponsor #ygrp-lc{
          font-family:Arial;}
          #ygrp-sponsor #ygrp-lc #hd{
          margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
          #ygrp-sponsor #ygrp-lc .ad{
          margin-bottom:10px;padding:0 0;}
          -->

          <!--

          #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;}
          #ygrp-mlmsg table {font-size:inherit;font:100%;}
          #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean, sans-serif;}
          #ygrp-mlmsg pre, code {font:115% monospace;}
          #ygrp-mlmsg * {line-height:1.22em;}
          #ygrp-text{
          font-family:Georgia;
          }
          #ygrp-text p{
          margin:0 0 1em 0;}
          #ygrp-tpmsgs{
          font-family:Arial;
          clear:both;}
          #ygrp-vitnav{
          padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
          #ygrp-vitnav a{
          padding:0 1px;}
          #ygrp-actbar{
          clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
          #ygrp-actbar .left{
          float:left;white-space:nowrap;}
          .bld{font-weight:bold;}
          #ygrp-grft{
          font-family:Verdana;font-size:77%;padding:15px 0;}
          #ygrp-ft{
          font-family:verdana;font-size:77%;border-top:1px solid #666;
          padding:5px 0;
          }
          #ygrp-mlmsg #logo{
          padding-bottom:10px;}

          #ygrp-vital{
          background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
          #ygrp-vital #vithd{
          font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;}
          #ygrp-vital ul{
          padding:0;margin:2px 0;}
          #ygrp-vital ul li{
          list-style-type:none;clear:both;border:1px solid #e0ecee;
          }
          #ygrp-vital ul li .ct{
          font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;}
          #ygrp-vital ul li .cat{
          font-weight:bold;}
          #ygrp-vital a{
          text-decoration:none;}

          #ygrp-vital a:hover{
          text-decoration:underline;}

          #ygrp-sponsor #hd{
          color:#999;font-size:77%;}
          #ygrp-sponsor #ov{
          padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
          #ygrp-sponsor #ov ul{
          padding:0 0 0 8px;margin:0;}
          #ygrp-sponsor #ov li{
          list-style-type:square;padding:6px 0;font-size:77%;}
          #ygrp-sponsor #ov li a{
          text-decoration:none;font-size:130%;}
          #ygrp-sponsor #nc{
          background-color:#eee;margin-bottom:20px;padding:0 8px;}
          #ygrp-sponsor .ad{
          padding:8px 0;}
          #ygrp-sponsor .ad #hd1{
          font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;}
          #ygrp-sponsor .ad a{
          text-decoration:none;}
          #ygrp-sponsor .ad a:hover{
          text-decoration:underline;}
          #ygrp-sponsor .ad p{
          margin:0;}
          o{font-size:0;}
          .MsoNormal{
          margin:0 0 0 0;}
          #ygrp-text tt{
          font-size:120%;}
          blockquote{margin:0 0 0 4px;}
          .replbq{margin:4;}
          -->






          ____________________________________________________________________________________
          Looking for last minute shopping deals?
          Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

          [Non-text portions of this message have been removed]
        • David Portas
          ... A primary key could be any candidate key. Under the relational model it s pretty vague and imprecise to talk of any candidate key values changing because
          Message 4 of 17 , Mar 3, 2008
          • 0 Attachment
            On 03/03/2008, Andrew Gregovich <andrew_gregovich@...> wrote:
            >
            >
            > Primary keys are not just unique keys, the basic rule is that they never (ever!) change.

            A primary key could be any candidate key. Under the relational model
            it's pretty vague and imprecise to talk of any candidate key values
            "changing" because attribute values identify tuples and therefore a
            new value represents a new tuple.

            In more conceptual terms however, stability is one of the criteria
            recommended for choosing a primary key. Stability is a very important
            issue but it has never been an absolute requirement for choosing a
            primary key (see Codd, Date for example).

            Most DBMSs will of course support updates to keys irrespective of
            whether they are identified as primary keys or not. Developers tend to
            have trouble with this and will often prefer surrogate keys because
            they use application state in a manner that depends on stable keys in
            the database. Hence the somewhat lazy misconception that the only
            valid keys are based on attributes that can never change.

            --
            David Portas
          Your message has been successfully submitted and would be delivered to recipients shortly.