Loading ...
Sorry, an error occurred while loading the content.
Skip to search.
 

To go fast you should slow down

Expand Messages
  • Ben Hogan
    Does anyone have any references or other support for the suggestion that on a software development team if your goal it to deliver to market as quickly as
    Message 1 of 24 , Nov 28, 2004
      Does anyone have any references or other support for the suggestion
      that on a software development team if your goal it to deliver to
      market as quickly as possible, the best thing you can do is take your
      time, and avoid time pressure within the team?

      --
      Ben Hogan
      http://geekbeers.blogspot.com
      bwhogan AT gmail.com
    • J. B. Rainsberger
      ... There is a study in Peopleware that mentions that among a number of teams asked to complete a project, the most productivity (quickest finish) came from
      Message 2 of 24 , Nov 28, 2004
        Ben Hogan wrote:
        > Does anyone have any references or other support for the suggestion
        > that on a software development team if your goal it to deliver to
        > market as quickly as possible, the best thing you can do is take your
        > time, and avoid time pressure within the team?

        There is a study in Peopleware that mentions that among a number of
        teams asked to complete a project, the most productivity (quickest
        finish) came from the team with no schedule pressure at all. Look at
        table 5.3 on page 28 (of the 2nd edition). The conclusion is that one
        might get the more productivity by applying less schedule pressure, up
        to the limit point!

        Take care.
        --
        J. B. (Joe) Rainsberger
        Diaspar Software Services
        http://www.diasparsoftware.com
        Author, JUnit Recipes: Practical Methods for Programmer Testing
      • Jeff Grigg
        ... Teams perform best with /some/ time pressure. But too much pressure is destructive. The biggest timesavings come from *creative* solutions to problems.
        Message 3 of 24 , Nov 28, 2004
          --- Ben Hogan <bwhogan@g...> wrote:
          > Does anyone have any references or other support for the
          > suggestion that on a software development team if your
          > goal it to deliver to market as quickly as possible, the
          > best thing you can do is take your time, and avoid time
          > pressure within the team?

          Teams perform best with /some/ time pressure. But "too much"
          pressure is destructive. The biggest timesavings come from
          *creative* solutions to problems. Creativity is lost when people
          are in a panic rush.


          If time to market is critically important, a highly iterative
          approach is desirable. The most common objection is, "We can't let
          them have it without a full feature set; no one will buy it."
          Ask, "Why are we denying our customers the right to buy what they
          want? Are there no customers anywhere in the world who could use a
          reduced function set?" A highly iterative approach ensures that you
          always have a product to sell and ship -- even when it doesn't have
          all the functionality that some people wish they had.

          A highly iterative approach also enables you to be highly responsive
          to current customer needs. Suppose your product is half done and
          you find a great new customer who needs your product -- including
          some features you haven't implemented yet. Well, put their needs
          first, and implement those features now. You'll get a happy
          customer and a good revenue stream. This will enable you to
          implement the remaining features, needed by other future customers.
        • Ben Hogan
          Thanks for your reply Jeff, So how do you know what is the right amount of pressure? Would you say that taking 30 min breaks (perhaps going to a coffee shop) a
          Message 4 of 24 , Nov 28, 2004
            Thanks for your reply Jeff,

            So how do you know what is the right amount of pressure?

            Would you say that taking 30 min breaks (perhaps going to a coffee
            shop) a couple of times a day, as a team, makes you go faster? As you
            mentioned, this would probably give more time for creativity.

            Apart from DeMarco's works, indeed his whole book 'Slack' seems to
            suggest that less than 100% utilisation is best, has anyone used any
            other arguments in convincing their sponsors / management to let off
            on the accelerator?

            --
            Ben Hogan
            http://geekbeers.blogspot.com
            bwhogan AT gmail.com

            On Sun, 28 Nov 2004 16:40:37 -0000, Jeff Grigg <jeffgrigg@...> wrote:

            > Teams perform best with /some/ time pressure. But "too much"
            > pressure is destructive. The biggest timesavings come from
            > *creative* solutions to problems. Creativity is lost when people
            > are in a panic rush.
          • Ron Jeffries
            I d expect that working together in one room, and taking breaks whenever one felt like it, alone or not as one felt like it, would be even better. Ron Jeffries
            Message 5 of 24 , Nov 28, 2004
              I'd expect that working together in one room, and taking breaks whenever
              one felt like it, alone or not as one felt like it, would be even better.

              Ron Jeffries
              www.XProgramming.com
              The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer

              On Sunday, November 28, 2004, at 4:23:30 PM, Ben Hogan wrote:

              > Would you say that taking 30 min breaks (perhaps going to a coffee
              > shop) a couple of times a day, as a team, makes you go faster? As you
              > mentioned, this would probably give more time for creativity.

              End quotation from Ben Hogan, on Sunday, November 28, 2004, at 4:23:30 PM
            • Jeff Grigg
              Right: I think that the main thing the teams I see are lacking is communication among the members. I can beat my head against a problem for hours, not
              Message 6 of 24 , Nov 28, 2004
                Right: I think that the main thing the teams I see are lacking is
                communication among the members. I can beat my head against a
                problem for hours, not knowing that another team member has the
                answer right at hand. Somehow you have to get the team members
                talking with each other.

                Pair Programming seems like a good idea. ;->


                --- Ron Jeffries <ronjeffries@X...> wrote:
                > I'd expect that working together in one room, and taking
                > breaks whenever one felt like it, alone or not as one
                > felt like it, would be even better.

                > --- Ben Hogan wrote:
                >> Would you say that taking 30 min breaks (perhaps going
                >> to a coffee shop) a couple of times a day, as a team,
                >> makes you go faster? As you mentioned, this would
                >> probably give more time for creativity.
              • acockburn@aol.com
                In a message dated 11/28/2004 3:00:33 P.M. Mountain Standard Time, extremeprogramming@yahoogroups.com writes: Date: Sun, 28 Nov 2004 23:52:10 +1100 From: Ben
                Message 7 of 24 , Nov 28, 2004
                  In a message dated 11/28/2004 3:00:33 P.M. Mountain Standard Time,
                  extremeprogramming@yahoogroups.com writes:

                  Date: Sun, 28 Nov 2004 23:52:10 +1100
                  From: Ben Hogan <bwhogan@...>
                  Subject: To go fast you should slow down

                  Does anyone have any references or other support for the suggestion
                  that on a software development team if your goal it to deliver to
                  market as quickly as possible, the best thing you can do is take your
                  time, and avoid time pressure within the team?




                  --->
                  uh, Ben, I'd be awfully suspicious of such an article, because there are too
                  many variables.
                  One is what the time frame is (e.g. 2 months or 2 years).
                  The DeMarco experiment is a nice counterexample, but you can't extrapolate
                  from a result of one; too many things we don't know (e.g., maybe these were the
                  best programmers, the most insightful ones, maybe they sat in one room,
                  etc.).

                  There is argument for "don't burn them out", but I don't know of any
                  argument for any particular thresholds. ... which means it gets really hard to
                  announce when the start of burn-out occurs, and that going slower from there might
                  mean faster over a 1 year period.

                  sorry

                  ==============================================
                  Alistair Cockburn



                  [Non-text portions of this message have been removed]
                • Sean Gilbertson
                  I think it s a good idea to focus on quality and understanding your code, and not let other constraints preclude that desire. Of course, this is not to say
                  Message 8 of 24 , Nov 29, 2004
                    I think it's a good idea to focus on quality and understanding your code, and not let other constraints preclude that desire. Of course, this is not to say that you shouldn't create designs that are efficient and small.

                    On Sun, Nov 28, 2004 at 11:52:10PM +1100, Ben Hogan wrote:
                    >
                    > Does anyone have any references or other support for the suggestion
                    > that on a software development team if your goal it to deliver to
                    > market as quickly as possible, the best thing you can do is take your
                    > time, and avoid time pressure within the team?
                    >
                    > --
                    > Ben Hogan
                    > http://geekbeers.blogspot.com
                    > bwhogan AT gmail.com
                    >
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >

                    --
                    Sean Gilbertson
                    IT Systems/Software Developer
                  • Ben Hogan
                    Thanks for your reply Alistair, I agree that the DeMarco experiment is not enough draw any conclusions from. It would be nice if there was data on the effect
                    Message 9 of 24 , Dec 1 7:06 AM
                      Thanks for your reply Alistair,

                      I agree that the DeMarco experiment is not enough draw any conclusions from.

                      It would be nice if there was data on the effect of pressure in
                      software development, but are there other related works? Team
                      collaboration under pressure? Effect of pressure on morale? Support
                      for a link between morale and productivity?

                      Also, is there data on the effect of taking frequent breaks, perhaps
                      to support the notion that pressure inhibits creative problem solving?
                      And is there support for your (excellent) metaphor that software
                      development is a cooperative game of communication and invention?

                      --
                      Ben Hogan
                      http://geekbeers.blogspot.com
                      bwhogan AT gmail.com

                      On Sun, 28 Nov 2004 23:37:57 EST, acockburn@... <acockburn@...> wrote:
                      > From: Ben Hogan <bwhogan@...>
                      > Subject: To go fast you should slow down
                      >
                      > Does anyone have any references or other support for the suggestion
                      > that on a software development team if your goal it to deliver to
                      > market as quickly as possible, the best thing you can do is take your
                      > time, and avoid time pressure within the team?
                      >
                      > --->
                      > uh, Ben, I'd be awfully suspicious of such an article, because there are too
                      > many variables.
                      > One is what the time frame is (e.g. 2 months or 2 years).
                      > The DeMarco experiment is a nice counterexample, but you can't extrapolate
                      > from a result of one; too many things we don't know (e.g., maybe these were the
                      > best programmers, the most insightful ones, maybe they sat in one room,
                      > etc.).
                      >
                      > There is argument for "don't burn them out", but I don't know of any
                      > argument for any particular thresholds. ... which means it gets really hard to
                      > announce when the start of burn-out occurs, and that going slower from there might
                      > mean faster over a 1 year period.
                      >
                      > sorry
                      >
                      > ==============================================
                      > Alistair Cockburn
                    • aacockburn
                      ... One the one hand, I suspect a metaphor is by definition only a suggestion. One the other hand, I propose sw dev as a cooperative game as an economic and
                      Message 10 of 24 , Dec 1 8:30 AM
                        --- In extremeprogramming@yahoogroups.com, Ben Hogan <bwhogan@g...>
                        wrote:
                        > And is there support for your (excellent) metaphor that software
                        > development is a cooperative game of communication and invention?

                        One the one hand, I suspect a metaphor is by definition only a
                        suggestion. One the other hand, I propose "sw dev as a cooperative
                        game" as an economic and steering model, so it is more than a
                        metaphor.

                        Actually I don't know how to "test" it, other than personal
                        observation as to whether people and projects respond in an effective
                        fashion. In my highly biased opinion, people and projects do respond
                        well to the model. I've love it if someone could work out a way to
                        test it. (I suspect that would be like having asked, in 1968, to test
                        the idea of sw dev as an engineering discipline. It took 30 years
                        for anything looking like data to roll in enough to refute it).
                      • Stede Troisi
                        I was thinking about YAGNI yesterday. Normally, I see most people create a customer class that holds domain information and another class, say CustomerDb that
                        Message 11 of 24 , Dec 1 8:52 AM
                          I was thinking about YAGNI yesterday. Normally, I see
                          most people create a customer class that holds domain
                          information and another class, say CustomerDb that
                          persists the information from customer to a database.
                          This makes sense, becuase if I want to persist to
                          something different (like a flat file) I can create a
                          new class to handle it while leaving the domain class
                          intact.

                          But two objects that share the same basic fields
                          (customer) seems to go against YAGNI. Is this how most
                          people solve the problem or is there a better
                          solution?

                          Thanks,
                          Stede




                          __________________________________
                          Do you Yahoo!?
                          The all-new My Yahoo! - What will yours do?
                          http://my.yahoo.com
                        • Ron Jeffries
                          ... I like to consider issues like these by looking at the code. Have you some code we could look at, simplified, perhaps? Ideally with tests? Ron Jeffries
                          Message 12 of 24 , Dec 1 10:27 AM
                            On Wednesday, December 1, 2004, at 11:52:47 AM, Stede Troisi wrote:

                            > I was thinking about YAGNI yesterday. Normally, I see
                            > most people create a customer class that holds domain
                            > information and another class, say CustomerDb that
                            > persists the information from customer to a database.
                            > This makes sense, becuase if I want to persist to
                            > something different (like a flat file) I can create a
                            > new class to handle it while leaving the domain class
                            > intact.

                            > But two objects that share the same basic fields
                            > (customer) seems to go against YAGNI. Is this how most
                            > people solve the problem or is there a better
                            > solution?

                            I like to consider issues like these by looking at the code. Have you some
                            code we could look at, simplified, perhaps? Ideally with tests?

                            Ron Jeffries
                            www.XProgramming.com
                            This is how I develop software.
                            Take the parts that make sense to you.
                            Ignore the rest.
                          • Ramon Leon
                            YouArentGonnaNeedIt is only one of many principles, you have to balance it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to making sure
                            Message 13 of 24 , Dec 1 10:29 AM
                              YouArentGonnaNeedIt is only one of many principles, you have to balance
                              it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to
                              making sure each class only has one responsibility, and you are gonna
                              need that. YouArentGonnaNeedIt is not a justification to violate basic
                              good OO principles like SingleResponsibilityPrinciple. In the java
                              community, I'm pretty sure most people just use existing open source
                              object mapping layers, in the .NET world, most are still hacking up
                              their own private implementation because there isn't any really
                              outstanding open source implementations yet.

                              > -----Original Message-----
                              > From: Stede Troisi [mailto:stedetro@...]
                              > Sent: Wednesday, December 01, 2004 9:53 AM
                              > To: extremeprogramming@yahoogroups.com
                              > Subject: [XP] [OT] Delegation and YAGNI!
                              >
                              >
                              > I was thinking about YAGNI yesterday. Normally, I see most
                              > people create a customer class that holds domain information
                              > and another class, say CustomerDb that persists the
                              > information from customer to a database.
                              > This makes sense, becuase if I want to persist to something
                              > different (like a flat file) I can create a new class to
                              > handle it while leaving the domain class intact.
                              >
                              > But two objects that share the same basic fields
                              > (customer) seems to go against YAGNI. Is this how most people
                              > solve the problem or is there a better solution?
                              >
                              > Thanks,
                              > Stede
                              >
                              >
                              >
                              >
                              > __________________________________
                              > Do you Yahoo!?
                              > The all-new My Yahoo! - What will yours do?
                              > http://my.yahoo.com
                              >
                              >
                              > To Post a message, send it to: extremeprogramming@...
                              >
                              > To Unsubscribe, send a blank message to:
                              > extremeprogramming-unsubscribe@...
                              >
                              > ad-free courtesy of objectmentor.com
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • Jeff Grigg
                              ... In other words, put all persistence code in /one/ place -- not one per business class. Most per-class logic will be data driven, and hence generic. ...
                              Message 14 of 24 , Dec 1 10:57 AM
                                --- "Ramon Leon" <rleon@i...> wrote:
                                > [...] In the java community, I'm pretty sure most people
                                > just use existing open source object mapping layers, in
                                > the .NET world, most are still hacking up their own
                                > private implementation because there isn't any really
                                > outstanding open source implementations yet.

                                In other words, put all persistence code in /one/ place -- not one
                                per business class. Most per-class logic will be data driven, and
                                hence generic.


                                > --- From: Stede Troisi [mailto:stedetro@y...]
                                >> I was thinking about YAGNI yesterday. [...]
                                >> [...] if I want to persist to something different (like
                                >> a flat file) I can create a new class to handle it while
                                >> leaving the domain class intact.

                                *This* is the right point to say "You Aren't Going to Need It" --
                                *don't* complicate your design now with the justification that, "Some
                                day we might want to persist to XML instead of the database."

                                >> Is this how most people solve the problem or is there
                                >> a better solution?

                                Sure there's a better solution: Object Prevalence. Don't persist
                                your objects to a relational database. You don't need it. ;->

                                http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ
                              • Steven Gordon
                                Why was this considered OT?? One way YAGNI applies in this kind of situation is that the stories asking for visible business functionality should be separate
                                Message 15 of 24 , Dec 1 11:13 AM
                                  Why was this considered OT??

                                  One way YAGNI applies in this kind of situation is that the stories
                                  asking for visible business functionality should be separate from
                                  the stories asking for persistance functionality. Given the
                                  dependencies between those stories, the business functionality
                                  stories almost always have greater business value to the customer
                                  than the persistance stories.

                                  Persistance is totally YAGNI when implementing the business
                                  functionality stories, so you first end up with a Customer class
                                  that provides the visible functionality your customer needs (via
                                  iterative feedback) with tests that verify its behavior.

                                  Then, when the persistance stories are the highest priority
                                  stories not yet implemented, persistance is no longer YAGNI.
                                  DoSimpleThings, ExpressiveCode, SingleResponsibilityPrinciple,
                                  etc. will then lead to building a data access layer (or
                                  leveraging an existing framework). Refactoring (i.e.,
                                  continuously applying OnceAndOnlyOnce) will keep it as simple
                                  as possible.

                                  If the original question was whether having virtually identical
                                  field names in the Customer object, the database, and the data
                                  access layer mediating them constitutes duplication, that appears
                                  to me to be a form of duplication whose elimination would likely
                                  lead to code that is far more difficult to understand and maintain
                                  than the code with the duplicative field names.

                                  Consider CMP in J2EE which is essentially driven by meta-data
                                  expressed in XML files. I have found CMP frustrating because I
                                  cannot refactor the code (or the database) without carefully
                                  editing that XML file. It does not feel like OnceAndOnlyOnce when
                                  I have to keep the database, code, and XML descriptors in synch.
                                  Of course, an Eclipse Plugin with XDOCLET-like functionality
                                  could automate a lot of the synchronization issues away.

                                  Steven A. Gordon, Ph.D.
                                  Manager, Software Factory
                                  Arizona State University
                                  PO Box 875506
                                  Tempe, AZ 85287-9509
                                  http://sf.asu.edu
                                  (480)-727-6271



                                  -----Original Message-----
                                  From: Ramon Leon [mailto:rleon@...]
                                  Sent: Wednesday, December 01, 2004 11:29 AM
                                  To: extremeprogramming@yahoogroups.com
                                  Subject: RE: [XP] [OT] Delegation and YAGNI!



                                  YouArentGonnaNeedIt is only one of many principles, you have to balance
                                  it with the others. OnceAndOnlyOnce and DoSimpleThings will lead you to
                                  making sure each class only has one responsibility, and you are gonna
                                  need that. YouArentGonnaNeedIt is not a justification to violate basic
                                  good OO principles like SingleResponsibilityPrinciple. In the java
                                  community, I'm pretty sure most people just use existing open source
                                  object mapping layers, in the .NET world, most are still hacking up
                                  their own private implementation because there isn't any really
                                  outstanding open source implementations yet.

                                  > -----Original Message-----
                                  > From: Stede Troisi [mailto:stedetro@...]
                                  > Sent: Wednesday, December 01, 2004 9:53 AM
                                  > To: extremeprogramming@yahoogroups.com
                                  > Subject: [XP] [OT] Delegation and YAGNI!
                                  >
                                  >
                                  > I was thinking about YAGNI yesterday. Normally, I see most
                                  > people create a customer class that holds domain information
                                  > and another class, say CustomerDb that persists the
                                  > information from customer to a database.
                                  > This makes sense, becuase if I want to persist to something
                                  > different (like a flat file) I can create a new class to
                                  > handle it while leaving the domain class intact.
                                  >
                                  > But two objects that share the same basic fields
                                  > (customer) seems to go against YAGNI. Is this how most people
                                  > solve the problem or is there a better solution?
                                  >
                                  > Thanks,
                                  > Stede
                                  >
                                  >
                                  >
                                  >
                                  > __________________________________
                                  > Do you Yahoo!?
                                  > The all-new My Yahoo! - What will yours do?
                                  > http://my.yahoo.com
                                  >
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to:
                                  > extremeprogramming-unsubscribe@...
                                  >
                                  > ad-free courtesy of objectmentor.com
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >


                                  To Post a message, send it to: extremeprogramming@...

                                  To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                  ad-free courtesy of objectmentor.com
                                  Yahoo! Groups Links
                                • Luiz Esmiralha
                                  ... You stole my words. RDBMS, YAGNI. Definitely. Oh, by the way, Prevayler was created in Brazil. :)
                                  Message 16 of 24 , Dec 1 11:42 AM
                                    On Wed, 01 Dec 2004 18:57:14 -0000, Jeff Grigg <jeffgrigg@...> wrote:
                                    >
                                    > >> Is this how most people solve the problem or is there
                                    > >> a better solution?
                                    >
                                    > Sure there's a better solution: Object Prevalence. Don't persist
                                    > your objects to a relational database. You don't need it. ;->
                                    >
                                    > http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ
                                    >

                                    You stole my words. RDBMS, YAGNI. Definitely. Oh, by the way,
                                    Prevayler was created in Brazil. :)
                                  • Jeff Grigg
                                    ... And so would a good naming standard. With appropriate automation. Consider: Suppose the Customer class was stored in the CUSTOMER table, and the Employee
                                    Message 17 of 24 , Dec 1 1:12 PM
                                      --- Steven Gordon <sagordon@a...> wrote:
                                      > [...] It does not feel like OnceAndOnlyOnce when I have
                                      > to keep the database, code, and XML descriptors in synch.
                                      > Of course, an Eclipse Plugin with XDOCLET-like functionality
                                      > could automate a lot of the synchronization issues away.

                                      And so would a good naming standard. With appropriate automation.

                                      Consider:
                                      Suppose the Customer class was stored in the CUSTOMER table, and the
                                      Employee class in the EMPLOYEE table. Why is the source of this
                                      cross-reference data an XML file, rather than a general rule?

                                      Same for columns: Suppose the 'firstName' attribute is stored in
                                      the 'FIRST_NAME' column. If you had naming standards and rules,
                                      you'd hardly need a cross-reference file.
                                    • Olson, Curtis B
                                      ... OK, but.... Legacy databases are not always so clean. Sometimes the attributes of a single object may come from more than one source table (or even from
                                      Message 18 of 24 , Dec 1 1:21 PM
                                        > From: Jeff Grigg [mailto:jeffgrigg@...]
                                        > Sent: Wednesday, December 01, 2004 4:13 PM

                                        > Consider:
                                        > Suppose the Customer class was stored in the CUSTOMER table, and the
                                        > Employee class in the EMPLOYEE table. Why is the source of this
                                        > cross-reference data an XML file, rather than a general rule?
                                        >
                                        > Same for columns: Suppose the 'firstName' attribute is stored in
                                        > the 'FIRST_NAME' column. If you had naming standards and rules,
                                        > you'd hardly need a cross-reference file.

                                        OK, but....

                                        Legacy databases are not always so clean. Sometimes the attributes of a
                                        single object may come from more than one source table (or even from
                                        non-DBMS sources).

                                        Cheers,
                                        Curtis
                                      • Luiz Esmiralha
                                        ... And I don t think that a 1 to 1 relationship between tables and classes is the best way to go.
                                        Message 19 of 24 , Dec 1 1:36 PM
                                          On Wed, 1 Dec 2004 16:21:27 -0500, Olson, Curtis B <olsoncb@...> wrote:
                                          >
                                          > > From: Jeff Grigg [mailto:jeffgrigg@...]
                                          > > Sent: Wednesday, December 01, 2004 4:13 PM
                                          >
                                          > > Consider:
                                          > > Suppose the Customer class was stored in the CUSTOMER table, and the
                                          > > Employee class in the EMPLOYEE table. Why is the source of this
                                          > > cross-reference data an XML file, rather than a general rule?
                                          > >
                                          > > Same for columns: Suppose the 'firstName' attribute is stored in
                                          > > the 'FIRST_NAME' column. If you had naming standards and rules,
                                          > > you'd hardly need a cross-reference file.
                                          >
                                          > OK, but....
                                          >
                                          > Legacy databases are not always so clean. Sometimes the attributes of a
                                          > single object may come from more than one source table (or even from
                                          > non-DBMS sources).
                                          >
                                          > Cheers,
                                          > Curtis
                                          >

                                          And I don't think that a 1 to 1 relationship between tables and
                                          classes is the best way to go.
                                        • Steven Gordon
                                          If you are persisting in a relational database, impedance mismatch suggests that at some point the 1-1 correspondence will break down. One could elaborate the
                                          Message 20 of 24 , Dec 1 1:46 PM
                                            If you are persisting in a relational database, impedance
                                            mismatch suggests that at some point the 1-1 correspondence
                                            will break down. One could elaborate the naming convention
                                            to distinguish the names the classes and properties that
                                            have a 1-1 correspondence with a database entity from those
                                            that do not. Once you start down that road, it is difficult
                                            to know when to stop elaborating the naming convention. In
                                            any case, you would still need a mechanism to handle the
                                            mismatches.

                                            In a language like C#, using attributes to define the
                                            database mapping might be an interesting approach that
                                            would allow you to keep the mapping information with the
                                            class itself. Has anybody tried using attributes for that
                                            purpose?

                                            -----Original Message-----
                                            From: Jeff Grigg [mailto:jeffgrigg@...]
                                            Sent: Wednesday, December 01, 2004 2:13 PM
                                            To: extremeprogramming@yahoogroups.com
                                            Subject: Re: [XP] [OT] Delegation and YAGNI! And XML xref




                                            --- Steven Gordon <sagordon@a...> wrote:
                                            > [...] It does not feel like OnceAndOnlyOnce when I have
                                            > to keep the database, code, and XML descriptors in synch.
                                            > Of course, an Eclipse Plugin with XDOCLET-like functionality
                                            > could automate a lot of the synchronization issues away.

                                            And so would a good naming standard. With appropriate automation.

                                            Consider:
                                            Suppose the Customer class was stored in the CUSTOMER table, and the
                                            Employee class in the EMPLOYEE table. Why is the source of this
                                            cross-reference data an XML file, rather than a general rule?

                                            Same for columns: Suppose the 'firstName' attribute is stored in
                                            the 'FIRST_NAME' column. If you had naming standards and rules,
                                            you'd hardly need a cross-reference file.
                                          • Steve Bate
                                            ... I ve done it in Java using XDoclet and Hibernate. I ve also used O/R mapping attributes for automatically creating the database schema and associated
                                            Message 21 of 24 , Dec 1 3:00 PM
                                              > From: Steven Gordon [mailto:sagordon@...]
                                              > ...
                                              > In a language like C#, using attributes to define the
                                              > database mapping might be an interesting approach that
                                              > would allow you to keep the mapping information with the
                                              > class itself. Has anybody tried using attributes for that
                                              > purpose?

                                              I've done it in Java using XDoclet and Hibernate. I've also
                                              used O/R mapping attributes for automatically creating
                                              the database schema and associated tables. It's worked well
                                              for my purposes.

                                              Steve
                                            • Steven Gordon
                                              Did it ever constrain your ability to refactor your code? ... From: Steve Bate [mailto:steve@xplanner.org] Sent: Wednesday, December 01, 2004 4:00 PM To:
                                              Message 22 of 24 , Dec 1 3:21 PM
                                                Did it ever constrain your ability to refactor your code?

                                                -----Original Message-----
                                                From: Steve Bate [mailto:steve@...]
                                                Sent: Wednesday, December 01, 2004 4:00 PM
                                                To: extremeprogramming@yahoogroups.com
                                                Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref



                                                > From: Steven Gordon [mailto:sagordon@...]
                                                > ...
                                                > In a language like C#, using attributes to define the
                                                > database mapping might be an interesting approach that
                                                > would allow you to keep the mapping information with the
                                                > class itself. Has anybody tried using attributes for that
                                                > purpose?

                                                I've done it in Java using XDoclet and Hibernate. I've also
                                                used O/R mapping attributes for automatically creating
                                                the database schema and associated tables. It's worked well
                                                for my purposes.

                                                Steve
                                              • Steve Bate
                                                I don t think that it constrains it, although it can make it more challenging at times. The IDE doesn t always keep metadata in sync with the code after code
                                                Message 23 of 24 , Dec 1 3:45 PM
                                                  I don't think that it constrains it, although it can make
                                                  it more challenging at times. The IDE doesn't always keep
                                                  metadata in sync with the code after code elements have
                                                  been renamed. For example, metadata describing a relational
                                                  foreign key reference might be broken after renaming a
                                                  method. A good set of tests will catch these problems.

                                                  Steve

                                                  > -----Original Message-----
                                                  > From: Steven Gordon [mailto:sagordon@...]
                                                  > Sent: Wednesday, December 01, 2004 5:21 PM
                                                  > To: extremeprogramming@yahoogroups.com
                                                  > Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref
                                                  >
                                                  >
                                                  > Did it ever constrain your ability to refactor your code?
                                                  >
                                                  > -----Original Message-----
                                                  > From: Steve Bate [mailto:steve@...]
                                                  > Sent: Wednesday, December 01, 2004 4:00 PM
                                                  > To: extremeprogramming@yahoogroups.com
                                                  > Subject: RE: [XP] [OT] Delegation and YAGNI! And XML xref
                                                  >
                                                  >
                                                  >
                                                  > > From: Steven Gordon [mailto:sagordon@...]
                                                  > > ...
                                                  > > In a language like C#, using attributes to define the
                                                  > > database mapping might be an interesting approach that
                                                  > > would allow you to keep the mapping information with the
                                                  > > class itself. Has anybody tried using attributes for that
                                                  > > purpose?
                                                  >
                                                  > I've done it in Java using XDoclet and Hibernate. I've also
                                                  > used O/R mapping attributes for automatically creating
                                                  > the database schema and associated tables. It's worked well
                                                  > for my purposes.
                                                  >
                                                  > Steve
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  > To Post a message, send it to: extremeprogramming@...
                                                  >
                                                  > To Unsubscribe, send a blank message to: extremeprogramming-
                                                  > unsubscribe@...
                                                  >
                                                  > ad-free courtesy of objectmentor.com
                                                  > Yahoo! Groups Links
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                • Karl Scotland
                                                  ... Hi Ben, Have you looked at any of the Theory of Constraints literature? I m no expert, as I m only just discovering this aspect for myself, but it seems
                                                  Message 24 of 24 , Dec 2 12:51 AM
                                                    > -----Original Message-----
                                                    > From: Ben Hogan [mailto:bwhogan@...]
                                                    >
                                                    > Does anyone have any references or other support for the
                                                    > suggestion that on a software development team if your goal
                                                    > it to deliver to market as quickly as possible, the best
                                                    > thing you can do is take your time, and avoid time pressure
                                                    > within the team?

                                                    Hi Ben,

                                                    Have you looked at any of the Theory of Constraints literature? I'm no
                                                    expert, as I'm only just discovering this aspect for myself, but it
                                                    seems that there may be something there which will help you. I'm sure
                                                    there's someone on this list who may be able to be more specific! I'd
                                                    be interested if there is aswell...

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