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

Paul Graham's latest essay on programming

Expand Messages
  • protoiyer
    Hi, This is Suresh from Chennai, India. I am a newbie to the world of XP and TDD, though I am not a newbie to programming. I just finished reading XPX:Embrace
    Message 1 of 25 , Aug 26, 2007
    • 0 Attachment
      Hi,

      This is Suresh from Chennai, India. I am a newbie to the world of XP
      and TDD, though I am not a newbie to programming. I just finished
      reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD: By Example
      back to back.

      Needless to say, I am thoroughly impressed with the thought process,
      principles and values proposed by XP/TDD.

      Then I read this essay by Paul Graham, who is one of the most
      respected writer/programmer around (if I am not wrong):

      http://www.paulgraham.com/head.html

      This essay, in many ways, runs against the thought process of
      XP/TDD. It can even be called as belonging to the "old school of
      thought" on programming. I can actually relate to what he says since I
      have proved it to myself many times (programming without distraction,
      programming in late evening when I am alone etc.).

      So, I can see lots of value in what he proposes (since I am a
      professional developer and I can see way too many programmers who just
      can't "hold a program in their head", and I am sure it is not a
      problem faced by Indian Software Industry alone).

      However, XP seems to advocate a stand that this is not required, and
      that you can actually grow a program by concentrating on the parts
      under consideration (being test driven) at any point of time.

      Am I missing something here? Is there any real overlap between what
      XP/TDD advocates and what Graham says (about working alone, work in
      long stretches, holding the program in its entirety in one's head etc.)

      Thanks so much.

      Regards,
      Suresh.
    • Keith Ray
      my reactions to that article 1. Avoid distractions : pair programming helps with this. Focusing on the current iteration s stories also avoids distractions.
      Message 2 of 25 , Aug 27, 2007
      • 0 Attachment
        my reactions to that article

        "1. Avoid distractions" : pair programming helps with this. Focusing
        on the current iteration's stories also avoids distractions. I've
        personally found pair programming helpful in maintaining a shared
        mental state when I would have otherwise been distracted by answering
        someone's questions.

        "2. Work in long stretches" : he says "There will of course come a
        point where you get stupid because you're tired" - that time comes
        sooner than most people think. Sustainable pace is better in the long
        term. Take this advice with a grain of salt. However, Agile, Lean,
        Theory Of Constraints people have all said that multi-tasking is bad.

        "3. Use succinct languages" : Smalltalk is one of those languages, and
        guess who invented XP? Smalltalkers.

        "4. Keep rewriting your program." : this is old-school terminology for
        XP's "merciless refactoring".

        "5. Write rereadable code." XP's values include communication,
        intention-revealing names, unit tests that act as executable examples
        and acceptance tests that act as executable requirements, and pair
        partners who should make sure you write readable code.

        "6. Work in small groups." yup. XP is best for small teams.

        "7. Don't have multiple people editing the same piece of code." - he
        says "you can't safely redesign something other people are working on"
        but with acceptance tests and test-driven-development giving you
        nearly 90% code-coverage, you CAN redesign code that other people in
        the same team work on. Daily stand-up meetings to let people know
        what's going on, and pair programming, etc., ... you know.

        "8. Start small." yup. And start with the most important/valuable
        features because those will create the core of the architecture.



        On 8/26/07, protoiyer <protoiyer@...> wrote:
        > Hi,
        >
        > This is Suresh from Chennai, India. I am a newbie to the world of XP
        > and TDD, though I am not a newbie to programming. I just finished
        > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD: By Example
        > back to back.
        >
        > Needless to say, I am thoroughly impressed with the thought process,
        > principles and values proposed by XP/TDD.
        >
        > Then I read this essay by Paul Graham, who is one of the most
        > respected writer/programmer around (if I am not wrong):
        >
        > http://www.paulgraham.com/head.html
        >
        > This essay, in many ways, runs against the thought process of
        > XP/TDD. It can even be called as belonging to the "old school of
        > thought" on programming. I can actually relate to what he says since I
        > have proved it to myself many times (programming without distraction,
        > programming in late evening when I am alone etc.).
        >
        > So, I can see lots of value in what he proposes (since I am a
        > professional developer and I can see way too many programmers who just
        > can't "hold a program in their head", and I am sure it is not a
        > problem faced by Indian Software Industry alone).
        >
        > However, XP seems to advocate a stand that this is not required, and
        > that you can actually grow a program by concentrating on the parts
        > under consideration (being test driven) at any point of time.
        >
        > Am I missing something here? Is there any real overlap between what
        > XP/TDD advocates and what Graham says (about working alone, work in
        > long stretches, holding the program in its entirety in one's head etc.)
        >
        > Thanks so much.
        >
        > Regards,
        > Suresh.
        >
        >
        >
        > 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
        >
        >
        >
        >


        --
        C. Keith Ray
        http://industriallogic.com 866-540-8336 (toll free)
        http://homepage.mac.com/keithray/blog/index.html
      • protoiyer
        Thanks so much, Keith. You have managed to turn the points raised in Paul s essay (which I thought was running against the thought process of XP) to
        Message 3 of 25 , Aug 27, 2007
        • 0 Attachment
          Thanks so much, Keith. You have managed to turn the points raised in
          Paul's essay (which I thought was running against the thought process
          of XP) to successfully highlight the strengths of XP/TDD.

          I think I can see the light in a new perspective now!

          --- In extremeprogramming@yahoogroups.com, "Keith Ray" <keith.ray@...>
          wrote:
          >
          > my reactions to that article
          >
          > "1. Avoid distractions" : pair programming helps with this. Focusing
          > on the current iteration's stories also avoids distractions. I've
          > personally found pair programming helpful in maintaining a shared
          > mental state when I would have otherwise been distracted by answering
          > someone's questions.
          >
          > "2. Work in long stretches" : he says "There will of course come a
          > point where you get stupid because you're tired" - that time comes
          > sooner than most people think. Sustainable pace is better in the long
          > term. Take this advice with a grain of salt. However, Agile, Lean,
          > Theory Of Constraints people have all said that multi-tasking is bad.
          >
          > "3. Use succinct languages" : Smalltalk is one of those languages, and
          > guess who invented XP? Smalltalkers.
          >
          > "4. Keep rewriting your program." : this is old-school terminology for
          > XP's "merciless refactoring".
          >
          > "5. Write rereadable code." XP's values include communication,
          > intention-revealing names, unit tests that act as executable examples
          > and acceptance tests that act as executable requirements, and pair
          > partners who should make sure you write readable code.
          >
          > "6. Work in small groups." yup. XP is best for small teams.
          >
          > "7. Don't have multiple people editing the same piece of code." - he
          > says "you can't safely redesign something other people are working on"
          > but with acceptance tests and test-driven-development giving you
          > nearly 90% code-coverage, you CAN redesign code that other people in
          > the same team work on. Daily stand-up meetings to let people know
          > what's going on, and pair programming, etc., ... you know.
          >
          > "8. Start small." yup. And start with the most important/valuable
          > features because those will create the core of the architecture.
          >
          >
          >
          > On 8/26/07, protoiyer <protoiyer@...> wrote:
          > > Hi,
          > >
          > > This is Suresh from Chennai, India. I am a newbie to the world of XP
          > > and TDD, though I am not a newbie to programming. I just finished
          > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD: By Example
          > > back to back.
          > >
          > > Needless to say, I am thoroughly impressed with the thought process,
          > > principles and values proposed by XP/TDD.
          > >
          > > Then I read this essay by Paul Graham, who is one of the most
          > > respected writer/programmer around (if I am not wrong):
          > >
          > > http://www.paulgraham.com/head.html
          > >
          > > This essay, in many ways, runs against the thought process of
          > > XP/TDD. It can even be called as belonging to the "old school of
          > > thought" on programming. I can actually relate to what he says since I
          > > have proved it to myself many times (programming without distraction,
          > > programming in late evening when I am alone etc.).
          > >
          > > So, I can see lots of value in what he proposes (since I am a
          > > professional developer and I can see way too many programmers who just
          > > can't "hold a program in their head", and I am sure it is not a
          > > problem faced by Indian Software Industry alone).
          > >
          > > However, XP seems to advocate a stand that this is not required, and
          > > that you can actually grow a program by concentrating on the parts
          > > under consideration (being test driven) at any point of time.
          > >
          > > Am I missing something here? Is there any real overlap between what
          > > XP/TDD advocates and what Graham says (about working alone, work in
          > > long stretches, holding the program in its entirety in one's head
          etc.)
          > >
          > > Thanks so much.
          > >
          > > Regards,
          > > Suresh.
          > >
          > >
          > >
          > > 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
          > >
          > >
          > >
          > >
          >
          >
          > --
          > C. Keith Ray
          > http://industriallogic.com 866-540-8336 (toll free)
          > http://homepage.mac.com/keithray/blog/index.html
          >
        • William Pietri
          ... I think your instinct is correct; his advice doesn t really take XP approaches into account. However, I still think a lot of the attitude applies, just in
          Message 4 of 25 , Aug 28, 2007
          • 0 Attachment
            protoiyer wrote:
            > However, XP seems to advocate a stand that this is not required, and
            > that you can actually grow a program by concentrating on the parts
            > under consideration (being test driven) at any point of time.
            >
            > Am I missing something here? Is there any real overlap between what
            > XP/TDD advocates and what Graham says (about working alone, work in
            > long stretches, holding the program in its entirety in one's head etc.)
            >

            I think your instinct is correct; his advice doesn't really take XP
            approaches into account. However, I still think a lot of the attitude
            applies, just in different ways.

            He's right that the more context you have in your head at once, the
            better off you are. However, in XP, we manage that differently. Instead
            of keeping the context in one head, we share it among the team. Instead
            of expecting to remember everything, we write tests so that we get
            reminded of the little details when we need to. And we keep both our
            production code and our tests as readable as possible, so that the
            stored knowledge is easily retrieved.

            At least in my experience, this has three effects. One, because we have
            offloaded a lot of little details, what's in our heads is often broader
            or more subtle stuff. Two, with more perspectives, the solutions are
            better. And three, since we've built up a supporting context, it's safer
            to leave and pick up the next day.

            And I think there's something more subtle, too. Without fear that we
            have lost some crucial detail, we're braver. I don't think that makes a
            big difference early on, but it's crucial in allowing refactoring and
            cleanup of cruft that otherwise kills code bases.

            William


            --
            William Pietri - william@... - +1-415-643-1024
            Agile consulting, coaching, and development: http://www.scissor.com/
            Instant video gratification: http://www.sidereel.com/
          • Jim Standley
            This recommendation was interesting: You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs
            Message 5 of 25 , Sep 3, 2007
            • 0 Attachment
              This recommendation was interesting: "You can magnify the effect of a
              powerful language by using a style called bottom-up programming, where
              you write programs in multiple layers, the lower ones acting as
              programming languages for those above."

              You might work top down, where each layer is a specification for the
              language below it. Or as PJ Plauger wrote in "Programming on Purpose"
              some problems work best left to right, or right to left or inside to
              outside. ;-)

              William Pietri wrote:
              >
              > protoiyer wrote:
              > > However, XP seems to advocate a stand that this is not required, and
              > > that you can actually grow a program by concentrating on the parts
              > > under consideration (being test driven) at any point of time.
              > >
              > > Am I missing something here? Is there any real overlap between what
              > > XP/TDD advocates and what Graham says (about working alone, work in
              > > long stretches, holding the program in its entirety in one's head etc.)
              > >
              >
              > I think your instinct is correct; his advice doesn't really take XP
              > approaches into account. However, I still think a lot of the attitude
              > applies, just in different ways.
              >
              > He's right that the more context you have in your head at once, the
              > better off you are. However, in XP, we manage that differently. Instead
              > of keeping the context in one head, we share it among the team. Instead
              > of expecting to remember everything, we write tests so that we get
              > reminded of the little details when we need to. And we keep both our
              > production code and our tests as readable as possible, so that the
              > stored knowledge is easily retrieved.
              >
              > At least in my experience, this has three effects. One, because we have
              > offloaded a lot of little details, what's in our heads is often broader
              > or more subtle stuff. Two, with more perspectives, the solutions are
              > better. And three, since we've built up a supporting context, it's safer
              > to leave and pick up the next day.
              >
              > And I think there's something more subtle, too. Without fear that we
              > have lost some crucial detail, we're braver. I don't think that makes a
              > big difference early on, but it's crucial in allowing refactoring and
              > cleanup of cruft that otherwise kills code bases.
              >
              > William
              >
              > --
              > William Pietri - william@... <mailto:william%40scissor.com> -
              > +1-415-643-1024
              > Agile consulting, coaching, and development: http://www.scissor.com/
              > <http://www.scissor.com/>
              > Instant video gratification: http://www.sidereel.com/
              > <http://www.sidereel.com/>
              >
              >
            • Steven Gordon
              Exactly. Many people confound the final form with the order in which things were built. Just because the end result may be these kind of DSL layers does not
              Message 6 of 25 , Sep 3, 2007
              • 0 Attachment
                Exactly.

                Many people confound the final form with the order in which things were
                built. Just because the end result may be these kind of DSL layers does not
                mean that any one layer was designed or completed before any other layer.

                I say let the user stories guide the order in which parts of the eventual
                layers are built and let expressiveness and reuse guide how those parts are
                eventually assembled into coherent layers via refactoring.

                Steve

                On 9/3/07, Jim Standley <JLStandley@...> wrote:
                >
                > This recommendation was interesting: "You can magnify the effect of a
                > powerful language by using a style called bottom-up programming, where
                > you write programs in multiple layers, the lower ones acting as
                > programming languages for those above."
                >
                > You might work top down, where each layer is a specification for the
                > language below it. Or as PJ Plauger wrote in "Programming on Purpose"
                > some problems work best left to right, or right to left or inside to
                > outside. ;-)
                >
                > William Pietri wrote:
                > >
                > > protoiyer wrote:
                > > > However, XP seems to advocate a stand that this is not required, and
                > > > that you can actually grow a program by concentrating on the parts
                > > > under consideration (being test driven) at any point of time.
                > > >
                > > > Am I missing something here? Is there any real overlap between what
                > > > XP/TDD advocates and what Graham says (about working alone, work in
                > > > long stretches, holding the program in its entirety in one's head
                > etc.)
                > > >
                > >
                > > I think your instinct is correct; his advice doesn't really take XP
                > > approaches into account. However, I still think a lot of the attitude
                > > applies, just in different ways.
                > >
                > > He's right that the more context you have in your head at once, the
                > > better off you are. However, in XP, we manage that differently. Instead
                > > of keeping the context in one head, we share it among the team. Instead
                > > of expecting to remember everything, we write tests so that we get
                > > reminded of the little details when we need to. And we keep both our
                > > production code and our tests as readable as possible, so that the
                > > stored knowledge is easily retrieved.
                > >
                > > At least in my experience, this has three effects. One, because we have
                > > offloaded a lot of little details, what's in our heads is often broader
                > > or more subtle stuff. Two, with more perspectives, the solutions are
                > > better. And three, since we've built up a supporting context, it's safer
                > > to leave and pick up the next day.
                > >
                > > And I think there's something more subtle, too. Without fear that we
                > > have lost some crucial detail, we're braver. I don't think that makes a
                > > big difference early on, but it's crucial in allowing refactoring and
                > > cleanup of cruft that otherwise kills code bases.
                > >
                > > William
                > >
                > > --
                > > William Pietri - william@... <william%40scissor.com> <mailto:
                > william% <william%25>40scissor.com> -
                > > +1-415-643-1024
                > > Agile consulting, coaching, and development: http://www.scissor.com/
                > > <http://www.scissor.com/>
                > > Instant video gratification: http://www.sidereel.com/
                > > <http://www.sidereel.com/>
                > >
                > >
                >
                >
                >


                [Non-text portions of this message have been removed]
              • Craig Davidson
                Hi Suresh, One thing to remember is that Paul Graham s viewpoint is quite different to that of the traditional Agile approaches. As I understand it Extreme
                Message 7 of 25 , Sep 6, 2007
                • 0 Attachment
                  Hi Suresh,

                  One thing to remember is that Paul Graham's viewpoint
                  is quite different to that of the traditional Agile approaches.

                  As I understand it Extreme Programming and Scrum came out of corporate
                  environments,
                  where software is developed by programmers who are paid to deliver software
                  for money,
                  regardless of the success or failure of the business.

                  Paul Graham's viewpoint comes from non-corporate
                  entreprenurial environments populated by extremely bright individuals,
                  who are paid in equity who only really make money when/if the business is a
                  success.
                  Added to this the goals of these two viewpoints tend to be quite different,
                  because of one simple constraint:
                  - users of software in a corporation have to use the software they are told
                  to.
                  For me this changes the whole risk/reward equation, and discourages risk in
                  corporate environments.

                  In fact I personally believe Paul Graham's ideas is more agile than
                  approaches such as XP,
                  they are just unworkable within (many) corporate environments.
                  For me it's a great reminder that there are many paths to a destination.
                  And it's a great reminder to be mindfull of the surrounding constraints in
                  those practices I do apply.

                  Cheers

                  Craig.



                  On 27/08/07, protoiyer <protoiyer@...> wrote:
                  >
                  > Hi,
                  >
                  > This is Suresh from Chennai, India. I am a newbie to the world of XP
                  > and TDD, though I am not a newbie to programming. I just finished
                  > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD: By Example
                  > back to back.
                  >
                  > Needless to say, I am thoroughly impressed with the thought process,
                  > principles and values proposed by XP/TDD.
                  >
                  > Then I read this essay by Paul Graham, who is one of the most
                  > respected writer/programmer around (if I am not wrong):
                  >
                  > http://www.paulgraham.com/head.html
                  >
                  > This essay, in many ways, runs against the thought process of
                  > XP/TDD. It can even be called as belonging to the "old school of
                  > thought" on programming. I can actually relate to what he says since I
                  > have proved it to myself many times (programming without distraction,
                  > programming in late evening when I am alone etc.).
                  >
                  > So, I can see lots of value in what he proposes (since I am a
                  > professional developer and I can see way too many programmers who just
                  > can't "hold a program in their head", and I am sure it is not a
                  > problem faced by Indian Software Industry alone).
                  >
                  > However, XP seems to advocate a stand that this is not required, and
                  > that you can actually grow a program by concentrating on the parts
                  > under consideration (being test driven) at any point of time.
                  >
                  > Am I missing something here? Is there any real overlap between what
                  > XP/TDD advocates and what Graham says (about working alone, work in
                  > long stretches, holding the program in its entirety in one's head etc.)
                  >
                  > Thanks so much.
                  >
                  > Regards,
                  > Suresh.
                  >
                  >
                  >
                  > 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
                  >
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Charlie Poole
                  Hi Craig, ... It s amusing that one can say traditional Agile but I suppose it works for some definition of tradition. :-) ... I ll pass on commenting about
                  Message 8 of 25 , Sep 6, 2007
                  • 0 Attachment
                    Hi Craig,

                    > One thing to remember is that Paul Graham's viewpoint is
                    > quite different to that of the traditional Agile approaches.

                    It's amusing that one can say "traditional Agile" but I suppose
                    it works for some definition of tradition. :-)

                    > As I understand it Extreme Programming and Scrum came out of
                    > corporate environments, where software is developed by
                    > programmers who are paid to deliver software for money,
                    > regardless of the success or failure of the business.

                    I'll pass on commenting about Scrum, since this is the XP list.

                    There are many people practicing XP outside of corporate
                    environments. In fact, many of us feel that XP works better
                    in a product company than for internal IT.

                    When you say "came out of" are you refering to the well-known
                    first XP project? Or do you mean that the folks who thought
                    up XP all had jobs at one time or another? Neither of those
                    things seems all that relevant.

                    > Paul Graham's viewpoint comes from non-corporate
                    > entreprenurial environments populated by extremely bright
                    > individuals, who are paid in equity who only really make
                    > money when/if the business is a success.
                    > Added to this the goals of these two viewpoints tend to be
                    > quite different, because of one simple constraint:
                    > - users of software in a corporation have to use the software
                    > they are told to.

                    Such a pattern is not descriptive of a place where I would choose
                    to introduce XP. Of course, it exists, but I'm rather amazed that
                    you seem to feel that such a non-productive environment is somehow
                    characteristic of XP. Is that what you mean?

                    > For me this changes the whole risk/reward equation, and
                    > discourages risk in corporate environments.

                    Indeed. And risk-aversion and XP go together in your mind... how?

                    > In fact I personally believe Paul Graham's ideas is more
                    > agile than approaches such as XP, they are just unworkable
                    > within (many) corporate environments.

                    I'm forming the impression - at least from this post - that
                    you are not personally familiar with XP. Is that correct?

                    My own feeling is that "agility" is not a characteristic of
                    a methodology, but of a team. Some approaches function
                    best on teams that are already agile. Some approaches
                    encourage teams to be agile. Some do both. XP, as I've
                    seen it practiced and practiced it myself appears to do
                    both. How have you seen it practiced?

                    > For me it's a great reminder that there are many paths to a
                    > destination.

                    Yes

                    > And it's a great reminder to be mindfull of the surrounding
                    > constraints in those practices I do apply.

                    Yes

                    Charlie

                    > Cheers
                    >
                    > Craig.
                    >
                    >
                    >
                    > On 27/08/07, protoiyer <protoiyer@...> wrote:
                    > >
                    > > Hi,
                    > >
                    > > This is Suresh from Chennai, India. I am a newbie to the
                    > world of XP
                    > > and TDD, though I am not a newbie to programming. I just finished
                    > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                    > By Example
                    > > back to back.
                    > >
                    > > Needless to say, I am thoroughly impressed with the thought
                    > process,
                    > > principles and values proposed by XP/TDD.
                    > >
                    > > Then I read this essay by Paul Graham, who is one of the most
                    > > respected writer/programmer around (if I am not wrong):
                    > >
                    > > http://www.paulgraham.com/head.html
                    > >
                    > > This essay, in many ways, runs against the thought process
                    > of XP/TDD.
                    > > It can even be called as belonging to the "old school of
                    > thought" on
                    > > programming. I can actually relate to what he says since I
                    > have proved
                    > > it to myself many times (programming without distraction,
                    > programming
                    > > in late evening when I am alone etc.).
                    > >
                    > > So, I can see lots of value in what he proposes (since I am a
                    > > professional developer and I can see way too many
                    > programmers who just
                    > > can't "hold a program in their head", and I am sure it is not a
                    > > problem faced by Indian Software Industry alone).
                    > >
                    > > However, XP seems to advocate a stand that this is not
                    > required, and
                    > > that you can actually grow a program by concentrating on the parts
                    > > under consideration (being test driven) at any point of time.
                    > >
                    > > Am I missing something here? Is there any real overlap between what
                    > > XP/TDD advocates and what Graham says (about working alone, work in
                    > > long stretches, holding the program in its entirety in one's head
                    > > etc.)
                    > >
                    > > Thanks so much.
                    > >
                    > > Regards,
                    > > Suresh.
                    > >
                    > >
                    > >
                    > > 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
                    > >
                    > >
                    > >
                    > >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                    >
                    >
                    > 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
                    >
                    >
                    >
                    >
                  • Craig Davidson
                    Hi Charlie, Thanks for responding so thoughtfully to my post. I hope my responses help clarify my thoughts (which are by no means concrete). ... Both, I was
                    Message 9 of 25 , Sep 6, 2007
                    • 0 Attachment
                      Hi Charlie,

                      Thanks for responding so thoughtfully to my post.
                      I hope my responses help clarify my thoughts (which are by no means
                      concrete).

                      On 06/09/07, Charlie Poole <xp@...> wrote:

                      > Hi Craig,
                      >
                      > > One thing to remember is that Paul Graham's viewpoint is
                      > > quite different to that of the traditional Agile approaches.
                      >
                      > It's amusing that one can say "traditional Agile" but I suppose
                      > it works for some definition of tradition. :-)
                      >
                      > > As I understand it Extreme Programming and Scrum came out of
                      > > corporate environments, where software is developed by
                      > > programmers who are paid to deliver software for money,
                      > > regardless of the success or failure of the business.
                      >
                      > I'll pass on commenting about Scrum, since this is the XP list.
                      >
                      > There are many people practicing XP outside of corporate
                      > environments. In fact, many of us feel that XP works better
                      > in a product company than for internal IT.
                      >
                      > When you say "came out of" are you refering to the well-known
                      > first XP project? Or do you mean that the folks who thought
                      > up XP all had jobs at one time or another? Neither of those
                      > things seems all that relevant.




                      Both, I was referring to the C3 project
                      and the fact that XP's major drivers
                      are professional software developers who sell their services rather than
                      their products.
                      Why is it not relevant?
                      I believe Kent Beck once said that all methodologies are based on fear.
                      Are those fear's are based on experience and environment?






                      > > Paul Graham's viewpoint comes from non-corporate
                      > > entreprenurial environments populated by extremely bright
                      > > individuals, who are paid in equity who only really make
                      > > money when/if the business is a success.
                      > > Added to this the goals of these two viewpoints tend to be
                      > > quite different, because of one simple constraint:
                      > > - users of software in a corporation have to use the software
                      > > they are told to.
                      >
                      > Such a pattern is not descriptive of a place where I would choose
                      > to introduce XP. Of course, it exists, but I'm rather amazed that
                      > you seem to feel that such a non-productive environment is somehow
                      > characteristic of XP. Is that what you mean?



                      Absolutely not.
                      When I am being paid to write software by someone else,
                      and this is my primary pattern for earning money.
                      and I have no stake in the business, I love using XP.

                      However, when I am not being paid cash and instead take stake in the success
                      of business (i.e. paid in a equity)
                      I want far more involvement in the creation of stories and their
                      prioritisation.
                      I also find that in early stage start ups (Paul Graham's interest I think)
                      the team size is so small and flexible as to make some XP practices
                      overkill.
                      At least that is my experience anyway.



                      > > For me this changes the whole risk/reward equation, and
                      > > discourages risk in corporate environments.
                      >
                      > Indeed. And risk-aversion and XP go together in your mind... how?



                      It is not "risk aversion and XP" but instead "risk aversion and corporate
                      environments" that go together in my mind.
                      Although, as a programmer, if I make (more or less) the same money
                      regardless of whether the business succeeds or influences the risk/reward
                      equation for me.
                      Does it not for you?




                      > > In fact I personally believe Paul Graham's ideas is more
                      > > agile than approaches such as XP, they are just unworkable
                      > > within (many) corporate environments.
                      >
                      > I'm forming the impression - at least from this post - that
                      > you are not personally familiar with XP. Is that correct?



                      I've read pretty much all the "colour" (white, pink, green) books numerous
                      times,
                      along with pretty much everything that Kent and Ron have written that I can
                      get hold of,
                      XP has been a huge influence on the way I work,
                      and I've been using most of XP's practices (as I understand
                      them) successfully for over 5 years across a wide range of companies.

                      Don't get me wrong, I really enjoy working on XP projects,
                      I just also see there are other ways of doing things that sometimes fit
                      better in dependant on the environment.
                      And the smaller the project the less some practices (for me) seem relevant
                      (although some always seem relevant).




                      > My own feeling is that "agility" is not a characteristic of
                      > a methodology, but of a team. Some approaches function
                      > best on teams that are already agile. Some approaches
                      > encourage teams to be agile. Some do both. XP, as I've
                      > seen it practiced and practiced it myself appears to do
                      > both. How have you seen it practiced?



                      On the "agility" front, I totally agree.
                      I used the term as per responding to change and fitting with the values.
                      As part of a start up, you have much more freedom to say
                      "this is a really bad idea, lets do something else". (again only in my
                      experience)

                      XP as I've seen it practiced, goes like this,
                      the larger and more corporate environment the more people seem to care
                      whether they are "doing XP" or even worse "doing Agile",
                      the smaller and more entrepreneurial the environment the more I find people
                      interested in,
                      "is what we are doing working for us?", "is our product any good?", "do
                      people like it?"
                      I think this second perspective is far more healthy.

                      Again my viewpoint is limited by my own experiences.

                      I hope this clarifies where my head is at?
                      Cheers,

                      Craig





                      > > For me it's a great reminder that there are many paths to a
                      > > destination.
                      >
                      > Yes
                      >
                      > > And it's a great reminder to be mindfull of the surrounding
                      > > constraints in those practices I do apply.
                      >
                      > Yes
                      >
                      > Charlie
                      >
                      > > Cheers
                      > >
                      > > Craig.
                      > >
                      > >
                      > >
                      > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                      > > >
                      > > > Hi,
                      > > >
                      > > > This is Suresh from Chennai, India. I am a newbie to the
                      > > world of XP
                      > > > and TDD, though I am not a newbie to programming. I just finished
                      > > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                      > > By Example
                      > > > back to back.
                      > > >
                      > > > Needless to say, I am thoroughly impressed with the thought
                      > > process,
                      > > > principles and values proposed by XP/TDD.
                      > > >
                      > > > Then I read this essay by Paul Graham, who is one of the most
                      > > > respected writer/programmer around (if I am not wrong):
                      > > >
                      > > > http://www.paulgraham.com/head.html
                      > > >
                      > > > This essay, in many ways, runs against the thought process
                      > > of XP/TDD.
                      > > > It can even be called as belonging to the "old school of
                      > > thought" on
                      > > > programming. I can actually relate to what he says since I
                      > > have proved
                      > > > it to myself many times (programming without distraction,
                      > > programming
                      > > > in late evening when I am alone etc.).
                      > > >
                      > > > So, I can see lots of value in what he proposes (since I am a
                      > > > professional developer and I can see way too many
                      > > programmers who just
                      > > > can't "hold a program in their head", and I am sure it is not a
                      > > > problem faced by Indian Software Industry alone).
                      > > >
                      > > > However, XP seems to advocate a stand that this is not
                      > > required, and
                      > > > that you can actually grow a program by concentrating on the parts
                      > > > under consideration (being test driven) at any point of time.
                      > > >
                      > > > Am I missing something here? Is there any real overlap between what
                      > > > XP/TDD advocates and what Graham says (about working alone, work in
                      > > > long stretches, holding the program in its entirety in one's head
                      > > > etc.)
                      > > >
                      > > > Thanks so much.
                      > > >
                      > > > Regards,
                      > > > Suresh.
                      > > >
                      > > >
                      > > >
                      > > > 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
                      > > >
                      > > >
                      > > >
                      > > >
                      > >
                      > >
                      > > [Non-text portions of this message have been removed]
                      > >
                      > >
                      > >
                      > > 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
                      >
                      >
                      >
                      >


                      [Non-text portions of this message have been removed]
                    • Charlie Poole
                      Hi Craig, ... Good. It s an interesting area. ... I think this observation would be relevant to /explaining/ some characteristics of XP, once those
                      Message 10 of 25 , Sep 6, 2007
                      • 0 Attachment
                        Hi Craig,

                        > Thanks for responding so thoughtfully to my post.
                        > I hope my responses help clarify my thoughts (which are by no
                        > means concrete).

                        Good. It's an interesting area.

                        > > When you say "came out of" are you refering to the
                        > well-known first XP
                        > > project? Or do you mean that the folks who thought up XP
                        > all had jobs
                        > > at one time or another? Neither of those things seems all that
                        > > relevant.
                        >
                        > Both, I was referring to the C3 project
                        > and the fact that XP's major drivers
                        > are professional software developers who sell their services
                        > rather than their products.
                        > Why is it not relevant?
                        > I believe Kent Beck once said that all methodologies are
                        > based on fear.
                        > Are those fear's are based on experience and environment?

                        I think this observation would be relevant to /explaining/
                        some characteristics of XP, once those characteristics were
                        actually observed and identified. The origin of XP is not
                        relevant in demonstrating that XP has those characteristics.

                        > > > Paul Graham's viewpoint comes from non-corporate entreprenurial
                        > > > environments populated by extremely bright individuals,
                        > who are paid
                        > > > in equity who only really make money when/if the business is a
                        > > > success.
                        > > > Added to this the goals of these two viewpoints tend to be quite
                        > > > different, because of one simple constraint:
                        > > > - users of software in a corporation have to use the
                        > software they
                        > > > are told to.
                        > >
                        > > Such a pattern is not descriptive of a place where I would
                        > choose to
                        > > introduce XP. Of course, it exists, but I'm rather amazed that you
                        > > seem to feel that such a non-productive environment is somehow
                        > > characteristic of XP. Is that what you mean?
                        >
                        >
                        >
                        > Absolutely not.
                        > When I am being paid to write software by someone else, and
                        > this is my primary pattern for earning money.
                        > and I have no stake in the business, I love using XP.
                        >
                        > However, when I am not being paid cash and instead take stake
                        > in the success of business (i.e. paid in a equity) I want far
                        > more involvement in the creation of stories and their prioritisation.
                        > I also find that in early stage start ups (Paul Graham's
                        > interest I think) the team size is so small and flexible as
                        > to make some XP practices overkill.
                        > At least that is my experience anyway.

                        My experience is quite different. The more invested I am in the
                        success of a project, the moe I want to develop software in the
                        best way I know how. For me, this is XP. If I were closely involved
                        in the business, I would expect to sometimes take a customer role
                        and sometimes an implementor role in defining stories. These two
                        roles can sometimes be hard to juggle, but XP does nothing to
                        make it any harder than it is. I'm suspecting that part of your
                        definition of XP is that it includes some negatives: things that
                        the developers may /not/ do. I believe that's a misunderstanding,
                        an an unfortunate one at that, but even if you use such a
                        definition, it's possible to change hats.
                        >
                        >
                        > > > For me this changes the whole risk/reward equation, and
                        > discourages
                        > > > risk in corporate environments.
                        > >
                        > > Indeed. And risk-aversion and XP go together in your mind... how?
                        >
                        >
                        >
                        > It is not "risk aversion and XP" but instead "risk aversion
                        > and corporate environments" that go together in my mind.
                        > Although, as a programmer, if I make (more or less) the same
                        > money regardless of whether the business succeeds or
                        > influences the risk/reward equation for me.
                        > Does it not for you?

                        I find I am motivated by money but that it is neither the
                        only thing, nor the biggest thing, that motivates me.

                        In any case, since you said that XP fits best in corporate
                        environments and that they tend to be risk-adverse, I took
                        you to mean that the risk-adversion made them better for XP.

                        If that's not it, what does make corporate environments a
                        better place to do XP, in your view?
                        >
                        >
                        >
                        > > > In fact I personally believe Paul Graham's ideas is more
                        > agile than
                        > > > approaches such as XP, they are just unworkable within (many)
                        > > > corporate environments.
                        > >
                        > > I'm forming the impression - at least from this post - that you are
                        > > not personally familiar with XP. Is that correct?
                        >
                        >
                        >
                        > I've read pretty much all the "colour" (white, pink, green)
                        > books numerous times, along with pretty much everything that
                        > Kent and Ron have written that I can get hold of, XP has been
                        > a huge influence on the way I work, and I've been using most
                        > of XP's practices (as I understand
                        > them) successfully for over 5 years across a wide range of companies.
                        >
                        > Don't get me wrong, I really enjoy working on XP projects, I
                        > just also see there are other ways of doing things that
                        > sometimes fit better in dependant on the environment.
                        > And the smaller the project the less some practices (for me)
                        > seem relevant (although some always seem relevant).

                        What are some practices you would drop in a very small project?

                        > > My own feeling is that "agility" is not a characteristic of a
                        > > methodology, but of a team. Some approaches function best on teams
                        > > that are already agile. Some approaches encourage teams to
                        > be agile.
                        > > Some do both. XP, as I've seen it practiced and practiced it myself
                        > > appears to do both. How have you seen it practiced?
                        >
                        >
                        >
                        > On the "agility" front, I totally agree.
                        > I used the term as per responding to change and fitting with
                        > the values.
                        > As part of a start up, you have much more freedom to say
                        > "this is a really bad idea, lets do something else". (again only in my
                        > experience)

                        I agree - at least for some startups. I've seen a few where that
                        freedom was not available to programmers but only to engineers,
                        physicists, marketers, etc. but lets stick with the ideal.

                        > XP as I've seen it practiced, goes like this, the larger and
                        > more corporate environment the more people seem to care
                        > whether they are "doing XP" or even worse "doing Agile", the
                        > smaller and more entrepreneurial the environment the more I
                        > find people interested in, "is what we are doing working for
                        > us?", "is our product any good?", "do people like it?"
                        > I think this second perspective is far more healthy.
                        >
                        > Again my viewpoint is limited by my own experiences.

                        From the next-to-last paragraph, I'm thinking you may have run
                        into some nominal, but not necessarily true implementations of XP.
                        I say that because thinking about whether you do XP is generally
                        not a good sign, even - or especially - in an XP project. The
                        key thing about XP is to be delivering value to the business. If
                        you aren't thinking about that, you can't really be doing XP.

                        I realize this can sound very much like "If it's not working
                        it's not XP" but that's not what I'm saying. Ken S has said
                        something with regard to Scrum that applies here just as well:
                        the moment you start following a set of steps, you are no longer
                        being agile. [Approximate quote - I heard it a long time ago.]

                        I realize that XP often looks like "following a set of steps"
                        from the outside, but that's not what it is. Every XP team
                        is responsible for continually defining and refining the
                        practices it follows. In some startups that might mean
                        inventing a way to act like a customer some of the time
                        and a developer at other times.

                        > I hope this clarifies where my head is at?

                        I understand better now, although I don't agree. Your description
                        of how things work in a startup sounds much more agile to me
                        than your description of "agile" in a corporate setting - the
                        latter sounds decidedly unagile, in fact.

                        Charlie

                        > Cheers,
                        >
                        > Craig
                        >
                        >
                        >
                        >
                        >
                        > > > For me it's a great reminder that there are many paths to a
                        > > > destination.
                        > >
                        > > Yes
                        > >
                        > > > And it's a great reminder to be mindfull of the surrounding
                        > > > constraints in those practices I do apply.
                        > >
                        > > Yes
                        > >
                        > > Charlie
                        > >
                        > > > Cheers
                        > > >
                        > > > Craig.
                        > > >
                        > > >
                        > > >
                        > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                        > > > >
                        > > > > Hi,
                        > > > >
                        > > > > This is Suresh from Chennai, India. I am a newbie to the
                        > > > world of XP
                        > > > > and TDD, though I am not a newbie to programming. I
                        > just finished
                        > > > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                        > > > By Example
                        > > > > back to back.
                        > > > >
                        > > > > Needless to say, I am thoroughly impressed with the thought
                        > > > process,
                        > > > > principles and values proposed by XP/TDD.
                        > > > >
                        > > > > Then I read this essay by Paul Graham, who is one of the most
                        > > > > respected writer/programmer around (if I am not wrong):
                        > > > >
                        > > > > http://www.paulgraham.com/head.html
                        > > > >
                        > > > > This essay, in many ways, runs against the thought process
                        > > > of XP/TDD.
                        > > > > It can even be called as belonging to the "old school of
                        > > > thought" on
                        > > > > programming. I can actually relate to what he says since I
                        > > > have proved
                        > > > > it to myself many times (programming without distraction,
                        > > > programming
                        > > > > in late evening when I am alone etc.).
                        > > > >
                        > > > > So, I can see lots of value in what he proposes (since I am a
                        > > > > professional developer and I can see way too many
                        > > > programmers who just
                        > > > > can't "hold a program in their head", and I am sure it is not a
                        > > > > problem faced by Indian Software Industry alone).
                        > > > >
                        > > > > However, XP seems to advocate a stand that this is not
                        > > > required, and
                        > > > > that you can actually grow a program by concentrating
                        > on the parts
                        > > > > under consideration (being test driven) at any point of time.
                        > > > >
                        > > > > Am I missing something here? Is there any real overlap between
                        > > > > what XP/TDD advocates and what Graham says (about
                        > working alone,
                        > > > > work in long stretches, holding the program in its entirety in
                        > > > > one's head
                        > > > > etc.)
                        > > > >
                        > > > > Thanks so much.
                        > > > >
                        > > > > Regards,
                        > > > > Suresh.
                        > > > >
                        > > > >
                        > > > >
                        > > > > 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
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > >
                        > > >
                        > > > [Non-text portions of this message have been removed]
                        > > >
                        > > >
                        > > >
                        > > > 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
                        > >
                        > >
                        > >
                        > >
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        >
                        >
                        > 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
                        >
                        >
                        >
                        >
                      • Craig Davidson
                        Hi Charlie, I think you are confusing my views on/understanding XP with my observations of how I have seen XP practiced in some organisations? ... My
                        Message 11 of 25 , Sep 6, 2007
                        • 0 Attachment
                          Hi Charlie,

                          I think you are confusing
                          my views on/understanding XP
                          with my observations
                          of how I have seen XP practiced in some organisations?


                          On 06/09/07, Charlie Poole <xp@...> wrote:
                          >
                          > Hi Craig,
                          >
                          > > Thanks for responding so thoughtfully to my post.
                          > > I hope my responses help clarify my thoughts (which are by no
                          > > means concrete).
                          >
                          > Good. It's an interesting area.
                          >
                          > > > When you say "came out of" are you refering to the
                          > > well-known first XP
                          > > > project? Or do you mean that the folks who thought up XP
                          > > all had jobs
                          > > > at one time or another? Neither of those things seems all that
                          > > > relevant.
                          > >
                          > > Both, I was referring to the C3 project
                          > > and the fact that XP's major drivers
                          > > are professional software developers who sell their services
                          > > rather than their products.
                          > > Why is it not relevant?
                          > > I believe Kent Beck once said that all methodologies are
                          > > based on fear.
                          > > Are those fear's are based on experience and environment?
                          >
                          > I think this observation would be relevant to /explaining/
                          > some characteristics of XP, once those characteristics were
                          > actually observed and identified. The origin of XP is not
                          > relevant in demonstrating that XP has those characteristics.



                          > > > Paul Graham's viewpoint comes from non-corporate entreprenurial
                          > > > > environments populated by extremely bright individuals,
                          > > who are paid
                          > > > > in equity who only really make money when/if the business is a
                          > > > > success.
                          > > > > Added to this the goals of these two viewpoints tend to be quite
                          > > > > different, because of one simple constraint:
                          > > > > - users of software in a corporation have to use the
                          > > software they
                          > > > > are told to.
                          > > >
                          > > > Such a pattern is not descriptive of a place where I would
                          > > choose to
                          > > > introduce XP. Of course, it exists, but I'm rather amazed that you
                          > > > seem to feel that such a non-productive environment is somehow
                          > > > characteristic of XP. Is that what you mean?
                          > >
                          > >
                          > >
                          > > Absolutely not.
                          > > When I am being paid to write software by someone else, and
                          > > this is my primary pattern for earning money.
                          > > and I have no stake in the business, I love using XP.
                          > >
                          > > However, when I am not being paid cash and instead take stake
                          > > in the success of business (i.e. paid in a equity) I want far
                          > > more involvement in the creation of stories and their prioritisation.
                          > > I also find that in early stage start ups (Paul Graham's
                          > > interest I think) the team size is so small and flexible as
                          > > to make some XP practices overkill.
                          > > At least that is my experience anyway.
                          >
                          > My experience is quite different. The more invested I am in the
                          > success of a project, the moe I want to develop software in the
                          > best way I know how. For me, this is XP. If I were closely involved
                          > in the business, I would expect to sometimes take a customer role
                          > and sometimes an implementor role in defining stories. These two
                          > roles can sometimes be hard to juggle, but XP does nothing to
                          > make it any harder than it is. I'm suspecting that part of your
                          > definition of XP is that it includes some negatives: things that
                          > the developers may /not/ do. I believe that's a misunderstanding,
                          > an an unfortunate one at that, but even if you use such a
                          > definition, it's possible to change hats.




                          My understanding is that XP views it as a bad thing for people to take both
                          developer and customer roles.
                          *"A programmer was also the customer. I said that couldn't possibly work..."
                          XPEe1*
                          In the startups I've worked with, i've found it's actually pretty common -
                          you are your first customer.
                          From the sound of it though, you don't have a problem with that.


                          >
                          > >
                          > > > > For me this changes the whole risk/reward equation, and
                          > > discourages
                          > > > > risk in corporate environments.
                          > > >
                          > > > Indeed. And risk-aversion and XP go together in your mind... how?
                          > >
                          > >
                          > >
                          > > It is not "risk aversion and XP" but instead "risk aversion
                          > > and corporate environments" that go together in my mind.
                          > > Although, as a programmer, if I make (more or less) the same
                          > > money regardless of whether the business succeeds or
                          > > influences the risk/reward equation for me.
                          > > Does it not for you?
                          >
                          > I find I am motivated by money but that it is neither the
                          > only thing, nor the biggest thing, that motivates me.
                          >
                          > In any case, since you said that XP fits best in corporate
                          > environments and that they tend to be risk-adverse, I took
                          > you to mean that the risk-adversion made them better for XP.
                          >
                          > If that's not it, what does make corporate environments a
                          > better place to do XP, in your view?



                          That's not really my view.
                          It's more, that corporate environments are the ones where
                          I've observed people actually caring whether they are "doing XP" or not.
                          In startups, and when I am running projects (and working myself), I don't
                          really care,
                          I just want the software to be developed quickly, do what it needs to do,
                          and be confident of its quality.
                          If XP practices help, that's great, if not, who cares.


                          >
                          > >
                          > >
                          > > > > In fact I personally believe Paul Graham's ideas is more
                          > > agile than
                          > > > > approaches such as XP, they are just unworkable within (many)
                          > > > > corporate environments.
                          > > >
                          > > > I'm forming the impression - at least from this post - that you are
                          > > > not personally familiar with XP. Is that correct?
                          > >
                          > >
                          > >
                          > > I've read pretty much all the "colour" (white, pink, green)
                          > > books numerous times, along with pretty much everything that
                          > > Kent and Ron have written that I can get hold of, XP has been
                          > > a huge influence on the way I work, and I've been using most
                          > > of XP's practices (as I understand
                          > > them) successfully for over 5 years across a wide range of companies.
                          > >
                          > > Don't get me wrong, I really enjoy working on XP projects, I
                          > > just also see there are other ways of doing things that
                          > > sometimes fit better in dependant on the environment.
                          > > And the smaller the project the less some practices (for me)
                          > > seem relevant (although some always seem relevant).
                          >
                          > What are some practices you would drop in a very small project?


                          The biggest one is the demarcation between Customer and Programmer roles.
                          Though from the sound of it you don't seem to believe in this demarcation.

                          Continuous Integration.
                          With a few players, just running the build when you are finished a task
                          works better in my view.

                          40 hour week / sustainable pace
                          Often I find I adopt very different work patterns when totally free, than
                          the traditional working week.
                          Startups seem to give different energies than an office job.

                          Pair programming
                          I find that often in startup mode, we don't have a fixed location and are
                          working remotely.

                          Metaphor
                          I'm much more prone to Naive metaphor, though actually I never really use
                          this one.

                          Coding standards
                          Never found i've/we've needed one for 1, 2 or 3 man teams.

                          Collective code ownership
                          I find "truck count" is much less of an issue in early phase startups.

                          > > My own feeling is that "agility" is not a characteristic of a
                          > > > methodology, but of a team. Some approaches function best on teams
                          > > > that are already agile. Some approaches encourage teams to
                          > > be agile.
                          > > > Some do both. XP, as I've seen it practiced and practiced it myself
                          > > > appears to do both. How have you seen it practiced?
                          > >
                          > >
                          > >
                          > > On the "agility" front, I totally agree.
                          > > I used the term as per responding to change and fitting with
                          > > the values.
                          > > As part of a start up, you have much more freedom to say
                          > > "this is a really bad idea, lets do something else". (again only in my
                          > > experience)
                          >
                          > I agree - at least for some startups. I've seen a few where that
                          > freedom was not available to programmers but only to engineers,
                          > physicists, marketers, etc. but lets stick with the ideal.
                          >
                          > > XP as I've seen it practiced, goes like this, the larger and
                          > > more corporate environment the more people seem to care
                          > > whether they are "doing XP" or even worse "doing Agile", the
                          > > smaller and more entrepreneurial the environment the more I
                          > > find people interested in, "is what we are doing working for
                          > > us?", "is our product any good?", "do people like it?"
                          > > I think this second perspective is far more healthy.
                          > >
                          > > Again my viewpoint is limited by my own experiences.
                          >
                          > From the next-to-last paragraph, I'm thinking you may have run
                          > into some nominal, but not necessarily true implementations of XP.
                          > I say that because thinking about whether you do XP is generally
                          > not a good sign, even - or especially - in an XP project. The
                          > key thing about XP is to be delivering value to the business. If
                          > you aren't thinking about that, you can't really be doing XP.


                          I agree, I'm just reporting what I've observed.
                          At the current time XP (and especially "Agile") appears more interesting to
                          larger organisations.
                          Smaller ones are just getting on with it, not really calling what they do XP
                          - just calling it software development.
                          Picking up practices and dropping them as they see fit.

                          I realize this can sound very much like "If it's not working
                          > it's not XP" but that's not what I'm saying. Ken S has said
                          > something with regard to Scrum that applies here just as well:
                          > the moment you start following a set of steps, you are no longer
                          > being agile. [Approximate quote - I heard it a long time ago.]


                          I think what "working" means is different, depending on the environments.
                          If I achieved the productivity in my own and on shared small startup
                          projects
                          I find myself getting on very successful in corporate environments,
                          I would worry - and stop.

                          I realize that XP often looks like "following a set of steps"
                          > from the outside, but that's not what it is. Every XP team
                          > is responsible for continually defining and refining the
                          > practices it follows. In some startups that might mean
                          > inventing a way to act like a customer some of the time
                          > and a developer at other times.


                          I agree.

                          > I hope this clarifies where my head is at?
                          >
                          > I understand better now, although I don't agree. Your description
                          > of how things work in a startup sounds much more agile to me
                          > than your description of "agile" in a corporate setting - the
                          > latter sounds decidedly unagile, in fact.


                          I agree.
                          Although I notice that when in startup mode,
                          I am increasingly influenced less by the standard XP/Agile views than other
                          viewpoints,
                          say the Pragmatics, 37signals, Paul Graham et al, which offer similar though
                          often subtly different perspectives,
                          particularly with respect to the Customer / Programmer divide, which I see
                          as a false one.
                          And they don't often use the A-word (okay the Pragmatics do - actually quite
                          a lot) which I personally don't like.
                          Although obviously I remain an avid reader of XP list :-)

                          Does this better clarify? or confuse?

                          Cheers,

                          Craig



                          Charlie
                          >
                          > > Cheers,
                          > >
                          > > Craig
                          > >
                          > >
                          > >
                          > >
                          > >
                          > > > > For me it's a great reminder that there are many paths to a
                          > > > > destination.
                          > > >
                          > > > Yes
                          > > >
                          > > > > And it's a great reminder to be mindfull of the surrounding
                          > > > > constraints in those practices I do apply.
                          > > >
                          > > > Yes
                          > > >
                          > > > Charlie
                          > > >
                          > > > > Cheers
                          > > > >
                          > > > > Craig.
                          > > > >
                          > > > >
                          > > > >
                          > > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                          > > > > >
                          > > > > > Hi,
                          > > > > >
                          > > > > > This is Suresh from Chennai, India. I am a newbie to the
                          > > > > world of XP
                          > > > > > and TDD, though I am not a newbie to programming. I
                          > > just finished
                          > > > > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                          > > > > By Example
                          > > > > > back to back.
                          > > > > >
                          > > > > > Needless to say, I am thoroughly impressed with the thought
                          > > > > process,
                          > > > > > principles and values proposed by XP/TDD.
                          > > > > >
                          > > > > > Then I read this essay by Paul Graham, who is one of the most
                          > > > > > respected writer/programmer around (if I am not wrong):
                          > > > > >
                          > > > > > http://www.paulgraham.com/head.html
                          > > > > >
                          > > > > > This essay, in many ways, runs against the thought process
                          > > > > of XP/TDD.
                          > > > > > It can even be called as belonging to the "old school of
                          > > > > thought" on
                          > > > > > programming. I can actually relate to what he says since I
                          > > > > have proved
                          > > > > > it to myself many times (programming without distraction,
                          > > > > programming
                          > > > > > in late evening when I am alone etc.).
                          > > > > >
                          > > > > > So, I can see lots of value in what he proposes (since I am a
                          > > > > > professional developer and I can see way too many
                          > > > > programmers who just
                          > > > > > can't "hold a program in their head", and I am sure it is not a
                          > > > > > problem faced by Indian Software Industry alone).
                          > > > > >
                          > > > > > However, XP seems to advocate a stand that this is not
                          > > > > required, and
                          > > > > > that you can actually grow a program by concentrating
                          > > on the parts
                          > > > > > under consideration (being test driven) at any point of time.
                          > > > > >
                          > > > > > Am I missing something here? Is there any real overlap between
                          > > > > > what XP/TDD advocates and what Graham says (about
                          > > working alone,
                          > > > > > work in long stretches, holding the program in its entirety in
                          > > > > > one's head
                          > > > > > etc.)
                          > > > > >
                          > > > > > Thanks so much.
                          > > > > >
                          > > > > > Regards,
                          > > > > > Suresh.
                          > > > > >
                          > > > > >
                          > > > > >
                          > > > > > 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
                          > > > > >
                          > > > > >
                          > > > > >
                          > > > > >
                          > > > >
                          > > > >
                          > > > > [Non-text portions of this message have been removed]
                          > > > >
                          > > > >
                          > > > >
                          > > > > 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
                          > > >
                          > > >
                          > > >
                          > > >
                          > >
                          > >
                          > > [Non-text portions of this message have been removed]
                          > >
                          > >
                          > >
                          > > 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
                          >
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • Charlie Poole
                          Hi Craig, ... Possibly. That s an important distinction both intellectually and politically. By the latter, I mean that it s a not helpful to the general state
                          Message 12 of 25 , Sep 6, 2007
                          • 0 Attachment
                            Hi Craig,

                            > I think you are confusing
                            > my views on/understanding XP
                            > with my observations
                            > of how I have seen XP practiced in some organisations?

                            Possibly. That's an important distinction both intellectually
                            and politically. By the latter, I mean that it's a not helpful
                            to the general state of the art if we call an inadequate of XP,
                            "XP."

                            > My understanding is that XP views it as a bad thing for
                            > people to take both developer and customer roles.

                            Well, XP can't speak, but practitioners can. I'd say that
                            most situations I've seen where the same person tried to take
                            on both roles led to failure. This was always the programmer
                            trying to take on the customer role, in my experience.

                            However, the underlying reason it failed doesn't apply to
                            your situation. In my observations, the programmer wasn't
                            /really/ a customer, but was just trying to play a role.
                            In your example, the programmers /really/ are customers,
                            or at least stakeholders, which I believe makes a world
                            of difference.

                            However, even if a bunch of programmers get together to
                            build a company around a software product, I think it
                            works better if they don't /all/ try to be the Customer
                            all the time. They might even want to hire someone to
                            take on that role.

                            Personally, I've worked in a few startups and I've never
                            been hampered from expressing my views about how the
                            company could succeed by any tenets of XP.

                            > *"A programmer was also the customer. I said that couldn't
                            > possibly work..."
                            > XPEe1*

                            Here's the follow-on to this story, one paragraph later...

                            "Okay, the rules here say that a programmer can't be the
                            customer. In this case, the rules don't apply. What still
                            applies is the separation of technical an business decisions.
                            The whole team, the programmer/customer, and especially
                            the coach, must be aware of which hat the programmer/customer
                            is wearing at any given time. And the coach needs to be
                            aware that no matter how well the arrangement has worked
                            I the past, if they run into trouble, the dual role is
                            a likely cause of problems."

                            I'm not suggesting you deliberately misused the quote, but
                            I do think that something in your experience led you to
                            read it as absolute, when it's not quite so in reality.

                            I've seen this before with folks who see XP as an absolute
                            set of rules - not saying you see it that way, of course.
                            They miss the signals that indicate where thought and
                            judgement are needed and that misunderstanding seems to
                            me to say more about them than about XP.

                            > In the startups I've worked with, i've found it's actually
                            > pretty common - you are your first customer.
                            > From the sound of it though, you don't have a problem with that.

                            No, none at all. But after 35 years I'm pretty experienced at
                            playing multiple roles and keeping my head straight about which
                            role I'm in at a given time. I often give developers cautions
                            about trying to play both roles, in pretty much the same terms
                            that Kent used in XPE1.

                            > That's not really my view.
                            > It's more, that corporate environments are the ones where
                            > I've observed people actually caring whether they are "doing
                            > XP" or not.

                            Would that be management people, programmers or both? I'm curious.

                            > In startups, and when I am running projects (and working
                            > myself), I don't really care, I just want the software to be
                            > developed quickly, do what it needs to do, and be confident
                            > of its quality.
                            > If XP practices help, that's great, if not, who cares.

                            That would be my position on any project - corporate IT,
                            application provider, shrinkwrap, embedded, whatever...

                            I /believe/ that's the standard XP position as well, but
                            I could be wrong. Well, not really. :-)

                            I acknowledge that XP has at times been /read/ by some
                            people to mean something else. But they're wrong. ;-)

                            > > What are some practices you would drop in a very small project?
                            >
                            >
                            > The biggest one is the demarcation between Customer and
                            > Programmer roles.
                            > Though from the sound of it you don't seem to believe in this
                            > demarcation.

                            For one thing, it's not a practice, not one of the twelve, but
                            more like a guiding principle. I don't think you should "drop"
                            it, but loosen your understanding of it a bit. "Don't try to
                            be a customer and a developer without understanding the risks.
                            Don't try to be both at the same moment."

                            > Continuous Integration.
                            > With a few players, just running the build when you are
                            > finished a task works better in my view.

                            That's how it usually works. With fewer people, there are
                            fewer completions and fewer checkins. Hence, fewer CI builds.

                            > 40 hour week / sustainable pace
                            > Often I find I adopt very different work patterns when
                            > totally free, than the traditional working week.
                            > Startups seem to give different energies than an office job.

                            That's one reason the name was changed.

                            > Pair programming
                            > I find that often in startup mode, we don't have a fixed
                            > location and are working remotely.

                            I haven't tried remote pairing. I imagine it would be less
                            satisfying than the real thing. But this seems to be only
                            an accidental connection with startups. I know of lots of
                            corporate settings with distributed teams.

                            > Metaphor
                            > I'm much more prone to Naive metaphor, though actually I
                            > never really use this one.

                            It sounds like this isn't really a size difference then. FWIW,
                            I consider this one of the key practices and I don't care if
                            Kent dropped it. Naïve is OK in my book if that's what you've
                            got. The key is that the whole team has a shared understanding
                            of what you're doing. "Metaphor" is a metaphor for that
                            understanding. Startups usually have it in spades.

                            > Coding standards
                            > Never found i've/we've needed one for 1, 2 or 3 man teams.

                            Not needed because you all lay code out the same way and use
                            the same naming conventions without one? Or not neede because
                            you don't mind variations.

                            > Collective code ownership
                            > I find "truck count" is much less of an issue in early
                            > phase startups.

                            I'm surprised at that one. Generally, its in rigid corporate
                            environments that I have the most trouble with the notion
                            that everyone is responsible for all the code. In startups,
                            that's usually accepted right away - IME of course.

                            And "truck count" is only one reason for this practice.

                            > > From the next-to-last paragraph, I'm thinking you may have run into
                            > > some nominal, but not necessarily true implementations of XP.
                            > > I say that because thinking about whether you do XP is
                            > generally not a
                            > > good sign, even - or especially - in an XP project. The key thing
                            > > about XP is to be delivering value to the business. If you aren't
                            > > thinking about that, you can't really be doing XP.
                            >
                            >
                            > I agree, I'm just reporting what I've observed.
                            > At the current time XP (and especially "Agile") appears more
                            > interesting to larger organisations.
                            > Smaller ones are just getting on with it, not really calling
                            > what they do XP
                            > - just calling it software development.
                            > Picking up practices and dropping them as they see fit.

                            That's what most people seem to do in my experience. I've actually
                            never - in a rather long career - seen programmers attempt to
                            "standardize" what they do according to a methodology. That
                            sort of thing has always come from above.

                            If XP comes down from above, then the same thing is likely
                            to happen that has happened in the past. Programmers will
                            appear to conform to the extent they need to. Programmers
                            will not really do XP.

                            What's new with XP as compared to earlier approaches is that
                            imposition of it from above is /by definition/ not XP. Agility,
                            if defined in terms of results, can be successfully imposed,
                            but XP cannot be imposed without becoming non-XP.

                            > > I understand better now, although I don't agree. Your
                            > description of
                            > > how things work in a startup sounds much more agile to me than your
                            > > description of "agile" in a corporate setting - the latter sounds
                            > > decidedly unagile, in fact.
                            >
                            >
                            > I agree.
                            > Although I notice that when in startup mode, I am
                            > increasingly influenced less by the standard XP/Agile views

                            To the extent that there is a "standard" view, it's rather
                            fluid. XP teaches that we have to figure it out for each
                            project. So every time I do a project, I create yet another
                            precise implementation of XP. Multiply that by thousands
                            of people doing it. And that's not deviating from some
                            ideal of XP - that /is/ XP. Frankly, it's hard to get that
                            from most books, because it's hard to write a book without
                            telling people what to do.

                            > than other viewpoints, say the Pragmatics, 37signals, Paul
                            > Graham et al, which offer similar though often subtly
                            > different perspectives, particularly with respect to the
                            > Customer / Programmer divide, which I see as a false one.

                            I do too - but in the sense that it really isn't in XP to
                            the extent that you seem to have seen it. However, if you
                            mean that there need be no distinction at all in these
                            two roles - not people, but roles - then I disagree.

                            > And they don't often use the A-word (okay the Pragmatics do -
                            > actually quite a lot) which I personally don't like.
                            > Although obviously I remain an avid reader of XP list :-)

                            Generally, as an XP guy, I don't tend to use the A word either.
                            Most really experienced XP folk I know shy away from it.
                            Except that customers come and ask us about it. And people
                            come on this list, not noticing its name I suppose, and
                            ask about "agile." So we respond.

                            "Agile" is too soft a word, IMO, for us to say much useful
                            about it, although I'll try if pressed. The word was coined
                            as an umbrella term to describe approaches that had some
                            big differences, in addition to their similarities. It works
                            about as well as any such umbrella word but it's quite
                            confusing to try to talk about XP and Agile together.

                            > Does this better clarify? or confuse?

                            I think you're part of what I call the "Agile Backlash"
                            which seems to have engaged a lot of smart people lately.
                            Unfortuantely, it's not a reaction to anything particularly
                            agile, but to things that are called agile.

                            Charlie

                            > Cheers,
                            >
                            > Craig
                            >
                            >
                            >
                            > Charlie
                            > >
                            > > > Cheers,
                            > > >
                            > > > Craig
                            > > >
                            > > >
                            > > >
                            > > >
                            > > >
                            > > > > > For me it's a great reminder that there are many paths to a
                            > > > > > destination.
                            > > > >
                            > > > > Yes
                            > > > >
                            > > > > > And it's a great reminder to be mindfull of the surrounding
                            > > > > > constraints in those practices I do apply.
                            > > > >
                            > > > > Yes
                            > > > >
                            > > > > Charlie
                            > > > >
                            > > > > > Cheers
                            > > > > >
                            > > > > > Craig.
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                            > > > > > >
                            > > > > > > Hi,
                            > > > > > >
                            > > > > > > This is Suresh from Chennai, India. I am a newbie to the
                            > > > > > world of XP
                            > > > > > > and TDD, though I am not a newbie to programming. I
                            > > > just finished
                            > > > > > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                            > > > > > By Example
                            > > > > > > back to back.
                            > > > > > >
                            > > > > > > Needless to say, I am thoroughly impressed with the thought
                            > > > > > process,
                            > > > > > > principles and values proposed by XP/TDD.
                            > > > > > >
                            > > > > > > Then I read this essay by Paul Graham, who is one
                            > of the most
                            > > > > > > respected writer/programmer around (if I am not wrong):
                            > > > > > >
                            > > > > > > http://www.paulgraham.com/head.html
                            > > > > > >
                            > > > > > > This essay, in many ways, runs against the thought process
                            > > > > > of XP/TDD.
                            > > > > > > It can even be called as belonging to the "old school of
                            > > > > > thought" on
                            > > > > > > programming. I can actually relate to what he says since I
                            > > > > > have proved
                            > > > > > > it to myself many times (programming without distraction,
                            > > > > > programming
                            > > > > > > in late evening when I am alone etc.).
                            > > > > > >
                            > > > > > > So, I can see lots of value in what he proposes
                            > (since I am a
                            > > > > > > professional developer and I can see way too many
                            > > > > > programmers who just
                            > > > > > > can't "hold a program in their head", and I am sure
                            > it is not
                            > > > > > > a problem faced by Indian Software Industry alone).
                            > > > > > >
                            > > > > > > However, XP seems to advocate a stand that this is not
                            > > > > > required, and
                            > > > > > > that you can actually grow a program by concentrating
                            > > > on the parts
                            > > > > > > under consideration (being test driven) at any
                            > point of time.
                            > > > > > >
                            > > > > > > Am I missing something here? Is there any real
                            > overlap between
                            > > > > > > what XP/TDD advocates and what Graham says (about
                            > > > working alone,
                            > > > > > > work in long stretches, holding the program in its
                            > entirety in
                            > > > > > > one's head
                            > > > > > > etc.)
                            > > > > > >
                            > > > > > > Thanks so much.
                            > > > > > >
                            > > > > > > Regards,
                            > > > > > > Suresh.
                            > > > > > >
                            > > > > > >
                            > > > > > >
                            > > > > > > 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
                            > > > > > >
                            > > > > > >
                            > > > > > >
                            > > > > > >
                            > > > > >
                            > > > > >
                            > > > > > [Non-text portions of this message have been removed]
                            > > > > >
                            > > > > >
                            > > > > >
                            > > > > > 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
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > >
                            > > >
                            > > > [Non-text portions of this message have been removed]
                            > > >
                            > > >
                            > > >
                            > > > 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
                            > >
                            > >
                            > >
                            > >
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >
                            > 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
                            >
                            >
                            >
                            >
                          • Phlip
                            ... I am way too intellectually-challenged to do that. I use TDD essentially as a crutch, because I m not smart enough to program the way real Software
                            Message 13 of 25 , Sep 6, 2007
                            • 0 Attachment
                              Paul Graham wrote:

                              > A good programmer working intensively on his own code can hold it in his
                              > mind the way a mathematician holds a problem he's working on.

                              I am way too intellectually-challenged to do that. I use TDD essentially as
                              a crutch, because I'm not smart enough to program the way real Software
                              Engineers do. Or even - gods forbid! - real mathematicians.

                              I need the ability to look thru a soda straw at the code, and only perceive
                              one tiny bit of it at a time. That's why I leave a trail of tests, so I can
                              think about that tiny bit of code while _deliberately_ forgetting about the
                              rest of the code.

                              > Mathematicians don't answer questions by working them out on paper the way
                              > schoolchildren are taught to.

                              This is how people who are good at chess play it. Some people blaze thru the
                              startup sequences as fast as tournament ping-pong. They can "see the board".
                              The correct advice here is to work with a mental model of your code's state,
                              and refine from it to a useful solution.

                              So don't hold the whole program; just hold a whole /transition/ in your
                              head. You should be able to "see the board", and see several refactors and
                              upgrades into the near future.

                              In my experience pairing with junior and intermediate programmers, my great
                              challenge is not telling them each operation to do next, it is transferring
                              that "see the board" into their brains, so /they/ start thinking of each
                              next operation to do.

                              This requires cultivating breaks and distractions, too...

                              > Avoid distractions

                              Distractions allow your subconscious to consider a problem while your
                              consciousness unwinds and thinks about something irrelevant.
                              www.boingboing.net is a great help here!

                              > Distractions are bad for many types of work, but especially bad for
                              > programming, because programmers tend to operate at the limit of the
                              > detail they can handle.

                              Then don't do that. Use TDD and OO to compartmentalize the details; if it's
                              hard, fix what's slowing you down. The code quality and test fixtures should
                              constantly let you fall back into simply authoring new code. You should
                              cultivate the ability to sit around _operating_ the machine, instead of
                              _building_ the machine.

                              > The danger of a distraction depends not on how long it is, but on how much
                              > it scrambles your brain.

                              The correct advice here is your manager should control your environment to
                              make distractions optional. Developers should not hear phones ring, and
                              should not be trained to jump up and salute if a boss walks in. If you have
                              a lot in your brain, and it should be dismantled and resolved slowly, you
                              should be allowed to defer the interruption!

                              > Work in long stretches

                              Yes, when you are in a groove, time flies. Learn to experiencing such
                              grooves! However...

                              ...a well-known early-childhood teaching technique is to teach until babies
                              are involved in an operation, but don't keep going until they get tired.
                              Always stop while they are fresh, so when they return to this activity they
                              don't have bad memories.

                              > The optimum is not the limit you can physically endure. There's an
                              > advantage as well as a cost of breaking up a project. Sometimes when you
                              > return to a problem after a rest, you find your unconscious mind has left
                              > an answer waiting for you.

                              > Use succinct languages.

                              Use languages that let you write Domain Specific Languages. The longer a
                              module lives, the more time you should spend extending its metadata and its
                              emergent behavior. This explains SQL for databases, Regexp for lite parsing,
                              Lex for heavy parsing, YAML/JSON for lite data blocks, etc.

                              > You can magnify the effect of a powerful language by using a style called
                              > bottom-up programming, where you write programs in multiple layers, the
                              > lower ones acting as programming languages for those above. If you do this
                              > right, you only have to keep the topmost layer in your head.

                              That's another way to say DSLs...

                              > Keep rewriting your program.

                              You ... you mean Refactor Mercilessly?? (-;

                              > Write rereadable code

                              Use pairing and DSLs, and actually read that code!

                              > Work in small groups

                              Yay!

                              > Don't have multiple people editing the same piece of code... And of course
                              > you can't safely redesign something other people are working on.

                              Someone hasn't used enough developer-testing here...

                              > Start small

                              Yay!

                              --
                              Phlip
                              http://www.oreilly.com/catalog/9780596510657/
                              "Test Driven Ajax (on Rails)"
                              assert_xpath, assert_javascript, & assert_ajax
                            • Craig Davidson
                              Hi Charlie, I think we understand each other reasonably well. It seems I ve managed to digress onto the misapplication of XP in corporate environments, for
                              Message 14 of 25 , Sep 7, 2007
                              • 0 Attachment
                                Hi Charlie,

                                I think we understand each other reasonably well.

                                It seems I've managed to digress onto the misapplication of XP in corporate
                                environments,
                                for that I apologise (as that one has been done to death I think).

                                For me it is much less interesting than considering (non XP) experts (such
                                as Paul Graham's)
                                views of how we can go about building great software in small startups,
                                Which is interesting to me as my default mode of development is based in XP
                                practices.

                                I think your points are all very reasonable.

                                The one I'm most interested in is this:

                                "However, even if a bunch of programmers get together to
                                build a company around a software product, I think it
                                works better if they don't /all/ try to be the Customer
                                all the time. They might even want to hire someone to
                                take on that role."


                                I've heard this recommended before,
                                and I can't understand why they would want to do this
                                (the hiring someone to take on the customer role part).
                                It sounds very much like hiring a business analyst to me.
                                Here's why...

                                I've always believed that the Gold Owner and the Goal Doner should be as
                                close as possible.
                                (do people still use these terms?)
                                This makes simple economic sense as it provides a basic differentiator
                                between wants and needs.
                                (infinite wants, limited resources, etc.)

                                For a commissioned piece of software
                                (as in where someone is paying you to program) this is straight forward.
                                However, where the programmers are (in effect) the Gold Owners
                                (through providing their time and energy),
                                they should have a strong vision for the product,
                                they should regularly challenge that vision themselves,
                                and they should endeavour to be the first customer for their software.
                                If they don't want to use it who else will?

                                When the buck stops with you
                                I can't understand why you would want to offload that core responsibility to
                                somebody else
                                (and pay them for the privilege) ?

                                Does this make sense? Am I misunderstanding something?

                                Cheers,

                                Craig

                                On 07/09/07, Charlie Poole <xp@...> wrote:
                                >
                                > Hi Craig,
                                >
                                > > I think you are confusing
                                > > my views on/understanding XP
                                > > with my observations
                                > > of how I have seen XP practiced in some organisations?
                                >
                                > Possibly. That's an important distinction both intellectually
                                > and politically. By the latter, I mean that it's a not helpful
                                > to the general state of the art if we call an inadequate of XP,
                                > "XP."
                                >
                                > > My understanding is that XP views it as a bad thing for
                                > > people to take both developer and customer roles.
                                >
                                > Well, XP can't speak, but practitioners can. I'd say that
                                > most situations I've seen where the same person tried to take
                                > on both roles led to failure. This was always the programmer
                                > trying to take on the customer role, in my experience.
                                >
                                > However, the underlying reason it failed doesn't apply to
                                > your situation. In my observations, the programmer wasn't
                                > /really/ a customer, but was just trying to play a role.
                                > In your example, the programmers /really/ are customers,
                                > or at least stakeholders, which I believe makes a world
                                > of difference.
                                >
                                > However, even if a bunch of programmers get together to
                                > build a company around a software product, I think it
                                > works better if they don't /all/ try to be the Customer
                                > all the time. They might even want to hire someone to
                                > take on that role.
                                >
                                > Personally, I've worked in a few startups and I've never
                                > been hampered from expressing my views about how the
                                > company could succeed by any tenets of XP.
                                >
                                > > *"A programmer was also the customer. I said that couldn't
                                > > possibly work..."
                                > > XPEe1*
                                >
                                > Here's the follow-on to this story, one paragraph later...
                                >
                                > "Okay, the rules here say that a programmer can't be the
                                > customer. In this case, the rules don't apply. What still
                                > applies is the separation of technical an business decisions.
                                > The whole team, the programmer/customer, and especially
                                > the coach, must be aware of which hat the programmer/customer
                                > is wearing at any given time. And the coach needs to be
                                > aware that no matter how well the arrangement has worked
                                > I the past, if they run into trouble, the dual role is
                                > a likely cause of problems."
                                >
                                > I'm not suggesting you deliberately misused the quote, but
                                > I do think that something in your experience led you to
                                > read it as absolute, when it's not quite so in reality.
                                >
                                > I've seen this before with folks who see XP as an absolute
                                > set of rules - not saying you see it that way, of course.
                                > They miss the signals that indicate where thought and
                                > judgement are needed and that misunderstanding seems to
                                > me to say more about them than about XP.
                                >
                                > > In the startups I've worked with, i've found it's actually
                                > > pretty common - you are your first customer.
                                > > From the sound of it though, you don't have a problem with that.
                                >
                                > No, none at all. But after 35 years I'm pretty experienced at
                                > playing multiple roles and keeping my head straight about which
                                > role I'm in at a given time. I often give developers cautions
                                > about trying to play both roles, in pretty much the same terms
                                > that Kent used in XPE1.
                                >
                                > > That's not really my view.
                                > > It's more, that corporate environments are the ones where
                                > > I've observed people actually caring whether they are "doing
                                > > XP" or not.
                                >
                                > Would that be management people, programmers or both? I'm curious.
                                >
                                > > In startups, and when I am running projects (and working
                                > > myself), I don't really care, I just want the software to be
                                > > developed quickly, do what it needs to do, and be confident
                                > > of its quality.
                                > > If XP practices help, that's great, if not, who cares.
                                >
                                > That would be my position on any project - corporate IT,
                                > application provider, shrinkwrap, embedded, whatever...
                                >
                                > I /believe/ that's the standard XP position as well, but
                                > I could be wrong. Well, not really. :-)
                                >
                                > I acknowledge that XP has at times been /read/ by some
                                > people to mean something else. But they're wrong. ;-)
                                >
                                > > > What are some practices you would drop in a very small project?
                                > >
                                > >
                                > > The biggest one is the demarcation between Customer and
                                > > Programmer roles.
                                > > Though from the sound of it you don't seem to believe in this
                                > > demarcation.
                                >
                                > For one thing, it's not a practice, not one of the twelve, but
                                > more like a guiding principle. I don't think you should "drop"
                                > it, but loosen your understanding of it a bit. "Don't try to
                                > be a customer and a developer without understanding the risks.
                                > Don't try to be both at the same moment."
                                >
                                > > Continuous Integration.
                                > > With a few players, just running the build when you are
                                > > finished a task works better in my view.
                                >
                                > That's how it usually works. With fewer people, there are
                                > fewer completions and fewer checkins. Hence, fewer CI builds.
                                >
                                > > 40 hour week / sustainable pace
                                > > Often I find I adopt very different work patterns when
                                > > totally free, than the traditional working week.
                                > > Startups seem to give different energies than an office job.
                                >
                                > That's one reason the name was changed.
                                >
                                > > Pair programming
                                > > I find that often in startup mode, we don't have a fixed
                                > > location and are working remotely.
                                >
                                > I haven't tried remote pairing. I imagine it would be less
                                > satisfying than the real thing. But this seems to be only
                                > an accidental connection with startups. I know of lots of
                                > corporate settings with distributed teams.
                                >
                                > > Metaphor
                                > > I'm much more prone to Naive metaphor, though actually I
                                > > never really use this one.
                                >
                                > It sounds like this isn't really a size difference then. FWIW,
                                > I consider this one of the key practices and I don't care if
                                > Kent dropped it. Naïve is OK in my book if that's what you've
                                > got. The key is that the whole team has a shared understanding
                                > of what you're doing. "Metaphor" is a metaphor for that
                                > understanding. Startups usually have it in spades.
                                >
                                > > Coding standards
                                > > Never found i've/we've needed one for 1, 2 or 3 man teams.
                                >
                                > Not needed because you all lay code out the same way and use
                                > the same naming conventions without one? Or not neede because
                                > you don't mind variations.
                                >
                                > > Collective code ownership
                                > > I find "truck count" is much less of an issue in early
                                > > phase startups.
                                >
                                > I'm surprised at that one. Generally, its in rigid corporate
                                > environments that I have the most trouble with the notion
                                > that everyone is responsible for all the code. In startups,
                                > that's usually accepted right away - IME of course.
                                >
                                > And "truck count" is only one reason for this practice.
                                >
                                > > > From the next-to-last paragraph, I'm thinking you may have run into
                                > > > some nominal, but not necessarily true implementations of XP.
                                > > > I say that because thinking about whether you do XP is
                                > > generally not a
                                > > > good sign, even - or especially - in an XP project. The key thing
                                > > > about XP is to be delivering value to the business. If you aren't
                                > > > thinking about that, you can't really be doing XP.
                                > >
                                > >
                                > > I agree, I'm just reporting what I've observed.
                                > > At the current time XP (and especially "Agile") appears more
                                > > interesting to larger organisations.
                                > > Smaller ones are just getting on with it, not really calling
                                > > what they do XP
                                > > - just calling it software development.
                                > > Picking up practices and dropping them as they see fit.
                                >
                                > That's what most people seem to do in my experience. I've actually
                                > never - in a rather long career - seen programmers attempt to
                                > "standardize" what they do according to a methodology. That
                                > sort of thing has always come from above.
                                >
                                > If XP comes down from above, then the same thing is likely
                                > to happen that has happened in the past. Programmers will
                                > appear to conform to the extent they need to. Programmers
                                > will not really do XP.
                                >
                                > What's new with XP as compared to earlier approaches is that
                                > imposition of it from above is /by definition/ not XP. Agility,
                                > if defined in terms of results, can be successfully imposed,
                                > but XP cannot be imposed without becoming non-XP.
                                >
                                > > > I understand better now, although I don't agree. Your
                                > > description of
                                > > > how things work in a startup sounds much more agile to me than your
                                > > > description of "agile" in a corporate setting - the latter sounds
                                > > > decidedly unagile, in fact.
                                > >
                                > >
                                > > I agree.
                                > > Although I notice that when in startup mode, I am
                                > > increasingly influenced less by the standard XP/Agile views
                                >
                                > To the extent that there is a "standard" view, it's rather
                                > fluid. XP teaches that we have to figure it out for each
                                > project. So every time I do a project, I create yet another
                                > precise implementation of XP. Multiply that by thousands
                                > of people doing it. And that's not deviating from some
                                > ideal of XP - that /is/ XP. Frankly, it's hard to get that
                                > from most books, because it's hard to write a book without
                                > telling people what to do.
                                >
                                > > than other viewpoints, say the Pragmatics, 37signals, Paul
                                > > Graham et al, which offer similar though often subtly
                                > > different perspectives, particularly with respect to the
                                > > Customer / Programmer divide, which I see as a false one.
                                >
                                > I do too - but in the sense that it really isn't in XP to
                                > the extent that you seem to have seen it. However, if you
                                > mean that there need be no distinction at all in these
                                > two roles - not people, but roles - then I disagree.
                                >
                                > > And they don't often use the A-word (okay the Pragmatics do -
                                > > actually quite a lot) which I personally don't like.
                                > > Although obviously I remain an avid reader of XP list :-)
                                >
                                > Generally, as an XP guy, I don't tend to use the A word either.
                                > Most really experienced XP folk I know shy away from it.
                                > Except that customers come and ask us about it. And people
                                > come on this list, not noticing its name I suppose, and
                                > ask about "agile." So we respond.
                                >
                                > "Agile" is too soft a word, IMO, for us to say much useful
                                > about it, although I'll try if pressed. The word was coined
                                > as an umbrella term to describe approaches that had some
                                > big differences, in addition to their similarities. It works
                                > about as well as any such umbrella word but it's quite
                                > confusing to try to talk about XP and Agile together.
                                >
                                > > Does this better clarify? or confuse?
                                >
                                > I think you're part of what I call the "Agile Backlash"
                                > which seems to have engaged a lot of smart people lately.
                                > Unfortuantely, it's not a reaction to anything particularly
                                > agile, but to things that are called agile.
                                >
                                > Charlie
                                >
                                > > Cheers,
                                > >
                                > > Craig
                                > >
                                > >
                                > >
                                > > Charlie
                                > > >
                                > > > > Cheers,
                                > > > >
                                > > > > Craig
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > >
                                > > > > > > For me it's a great reminder that there are many paths to a
                                > > > > > > destination.
                                > > > > >
                                > > > > > Yes
                                > > > > >
                                > > > > > > And it's a great reminder to be mindfull of the surrounding
                                > > > > > > constraints in those practices I do apply.
                                > > > > >
                                > > > > > Yes
                                > > > > >
                                > > > > > Charlie
                                > > > > >
                                > > > > > > Cheers
                                > > > > > >
                                > > > > > > Craig.
                                > > > > > >
                                > > > > > >
                                > > > > > >
                                > > > > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                                > > > > > > >
                                > > > > > > > Hi,
                                > > > > > > >
                                > > > > > > > This is Suresh from Chennai, India. I am a newbie to the
                                > > > > > > world of XP
                                > > > > > > > and TDD, though I am not a newbie to programming. I
                                > > > > just finished
                                > > > > > > > reading XPX:Embrace Change -- Editions 1 and 2 -- and TDD:
                                > > > > > > By Example
                                > > > > > > > back to back.
                                > > > > > > >
                                > > > > > > > Needless to say, I am thoroughly impressed with the thought
                                > > > > > > process,
                                > > > > > > > principles and values proposed by XP/TDD.
                                > > > > > > >
                                > > > > > > > Then I read this essay by Paul Graham, who is one
                                > > of the most
                                > > > > > > > respected writer/programmer around (if I am not wrong):
                                > > > > > > >
                                > > > > > > > http://www.paulgraham.com/head.html
                                > > > > > > >
                                > > > > > > > This essay, in many ways, runs against the thought process
                                > > > > > > of XP/TDD.
                                > > > > > > > It can even be called as belonging to the "old school of
                                > > > > > > thought" on
                                > > > > > > > programming. I can actually relate to what he says since I
                                > > > > > > have proved
                                > > > > > > > it to myself many times (programming without distraction,
                                > > > > > > programming
                                > > > > > > > in late evening when I am alone etc.).
                                > > > > > > >
                                > > > > > > > So, I can see lots of value in what he proposes
                                > > (since I am a
                                > > > > > > > professional developer and I can see way too many
                                > > > > > > programmers who just
                                > > > > > > > can't "hold a program in their head", and I am sure
                                > > it is not
                                > > > > > > > a problem faced by Indian Software Industry alone).
                                > > > > > > >
                                > > > > > > > However, XP seems to advocate a stand that this is not
                                > > > > > > required, and
                                > > > > > > > that you can actually grow a program by concentrating
                                > > > > on the parts
                                > > > > > > > under consideration (being test driven) at any
                                > > point of time.
                                > > > > > > >
                                > > > > > > > Am I missing something here? Is there any real
                                > > overlap between
                                > > > > > > > what XP/TDD advocates and what Graham says (about
                                > > > > working alone,
                                > > > > > > > work in long stretches, holding the program in its
                                > > entirety in
                                > > > > > > > one's head
                                > > > > > > > etc.)
                                > > > > > > >
                                > > > > > > > Thanks so much.
                                > > > > > > >
                                > > > > > > > Regards,
                                > > > > > > > Suresh.
                                > > > > > > >
                                > > > > > > >
                                > > > > > > >
                                > > > > > > > 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
                                > > > > > > >
                                > > > > > > >
                                > > > > > > >
                                > > > > > > >
                                > > > > > >
                                > > > > > >
                                > > > > > > [Non-text portions of this message have been removed]
                                > > > > > >
                                > > > > > >
                                > > > > > >
                                > > > > > > 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
                                > > > > >
                                > > > > >
                                > > > > >
                                > > > > >
                                > > > >
                                > > > >
                                > > > > [Non-text portions of this message have been removed]
                                > > > >
                                > > > >
                                > > > >
                                > > > > 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
                                > > >
                                > > >
                                > > >
                                > > >
                                > >
                                > >
                                > > [Non-text portions of this message have been removed]
                                > >
                                > >
                                > >
                                > > 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
                                >
                                >
                                >
                                >


                                [Non-text portions of this message have been removed]
                              • Charlie Poole
                                Hi Craig, ... You are wise. :-) ... First of all, I said might even not ought to I ve known many successful companies that were made so by the hiring of a
                                Message 15 of 25 , Sep 7, 2007
                                • 0 Attachment
                                  Hi Craig,

                                  > It seems I've managed to digress onto the misapplication of
                                  > XP in corporate environments, for that I apologise (as that
                                  > one has been done to death I think).
                                  >
                                  > For me it is much less interesting than considering (non XP)
                                  > experts (such as Paul Graham's) views of how we can go about
                                  > building great software in small startups, Which is
                                  > interesting to me as my default mode of development is based
                                  > in XP practices.
                                  >
                                  > I think your points are all very reasonable.

                                  You are wise. :-)

                                  > The one I'm most interested in is this:
                                  >
                                  > "However, even if a bunch of programmers get together to
                                  > build a company around a software product, I think it works
                                  > better if they don't /all/ try to be the Customer all the
                                  > time. They might even want to hire someone to take on that role."
                                  >
                                  >
                                  > I've heard this recommended before,
                                  > and I can't understand why they would want to do this (the
                                  > hiring someone to take on the customer role part).
                                  > It sounds very much like hiring a business analyst to me.
                                  > Here's why...

                                  First of all, I said "might even" not "ought to"

                                  I've known many successful companies that were made so by the
                                  hiring of a business-oriented person (not a business analyst)
                                  who could help formulate something that can work in the market
                                  out of the (usually) more technical vision of the engineers
                                  who started the business.

                                  I've known other companies that didn't need to do that. It's
                                  just a strategy.

                                  Secondly, I think you're stretching what I wrote to mean more
                                  than I intended. When I say that a person should not try
                                  to play the customer and developer role at the same time,
                                  I mean something like "in the same conversation" or "in the
                                  same meeting" and not " in the same business" or "during the
                                  same lifetime." :-)

                                  > I've always believed that the Gold Owner and the Goal Doner
                                  > should be as close as possible.
                                  > (do people still use these terms?)

                                  Yes... at least I do. I don't know about "should" however,
                                  since it's not something that we can normally control.

                                  > This makes simple economic sense as it provides a basic
                                  > differentiator between wants and needs.
                                  > (infinite wants, limited resources, etc.)

                                  I don't think we can actually make rules as to who has these
                                  roles. It just is. Someone has the money. Someone has the goals.
                                  We can - of course - make mistakes if we create proxies for
                                  these folks, as we often do.

                                  > For a commissioned piece of software
                                  > (as in where someone is paying you to program) this is
                                  > straight forward.

                                  Frankly, I don't find it so. The same issues of suitability
                                  to purpose come up when one is doing work for hire. A true
                                  professional raises those issues in that context as well.

                                  > However, where the programmers are (in effect) the Gold
                                  > Owners (through providing their time and energy), they should
                                  > have a strong vision for the product, they should regularly
                                  > challenge that vision themselves, and they should endeavour
                                  > to be the first customer for their software.
                                  > If they don't want to use it who else will?

                                  The only problem I have with your statements is that you don't
                                  only seem to be applying them to a small group. In my view, this
                                  is /exactly/ what we want in every team and it's /precisely/
                                  what I try to achieve with XP... sometimes even with success.

                                  Practices like pairing, shared ownership, whole team and metaphor
                                  are all about maintenance of that strong, shared vision. Otherwise
                                  why do them?

                                  I'm also a little confused about the notion that programmers are
                                  the gold owners by virtue of providing their time and energy.
                                  Maybe I'm not understanding the sort of environment you mean.
                                  AFAIK, all programmers are expected to provide their time and
                                  energy. Generally they get some compensation. One exception I
                                  know of is in the open source world, where this issue of
                                  customer versus programmer role can be quite difficult at times.

                                  > When the buck stops with you
                                  > I can't understand why you would want to offload that core
                                  > responsibility to somebody else (and pay them for the privilege) ?

                                  I can't offload my responsibilities for any price. But I can pay
                                  someone to do things that I am less skilled at or don't have time
                                  to do. Someone in the Customer role may be the gold owner or the
                                  goal donor, but that's not usually the case. In smaller companies
                                  it's sometimes possible to do this

                                  > Does this make sense? Am I misunderstanding something?

                                  I have a strong suspicion that we are each missing something. :-)

                                  I'm not sure I entirely understand the situation you are describing.
                                  I don't think you're understanding what I mean when I stress that
                                  one cannot generally /simultaneously/ and /successfully/ be both
                                  implementor and customer. It's a very difficult thing to do. I
                                  speak as one who has both done it and seen it done several times.

                                  Charlie

                                  > Cheers,
                                  >
                                  > Craig
                                  >
                                  > On 07/09/07, Charlie Poole <xp@...> wrote:
                                  > >
                                  > > Hi Craig,
                                  > >
                                  > > > I think you are confusing
                                  > > > my views on/understanding XP
                                  > > > with my observations
                                  > > > of how I have seen XP practiced in some organisations?
                                  > >
                                  > > Possibly. That's an important distinction both intellectually and
                                  > > politically. By the latter, I mean that it's a not helpful to the
                                  > > general state of the art if we call an inadequate of XP, "XP."
                                  > >
                                  > > > My understanding is that XP views it as a bad thing for people to
                                  > > > take both developer and customer roles.
                                  > >
                                  > > Well, XP can't speak, but practitioners can. I'd say that most
                                  > > situations I've seen where the same person tried to take on
                                  > both roles
                                  > > led to failure. This was always the programmer trying to
                                  > take on the
                                  > > customer role, in my experience.
                                  > >
                                  > > However, the underlying reason it failed doesn't apply to your
                                  > > situation. In my observations, the programmer wasn't /really/ a
                                  > > customer, but was just trying to play a role.
                                  > > In your example, the programmers /really/ are customers, or
                                  > at least
                                  > > stakeholders, which I believe makes a world of difference.
                                  > >
                                  > > However, even if a bunch of programmers get together to build a
                                  > > company around a software product, I think it works better if they
                                  > > don't /all/ try to be the Customer all the time. They might
                                  > even want
                                  > > to hire someone to take on that role.
                                  > >
                                  > > Personally, I've worked in a few startups and I've never
                                  > been hampered
                                  > > from expressing my views about how the company could succeed by any
                                  > > tenets of XP.
                                  > >
                                  > > > *"A programmer was also the customer. I said that
                                  > couldn't possibly
                                  > > > work..."
                                  > > > XPEe1*
                                  > >
                                  > > Here's the follow-on to this story, one paragraph later...
                                  > >
                                  > > "Okay, the rules here say that a programmer can't be the
                                  > customer. In
                                  > > this case, the rules don't apply. What still applies is the
                                  > separation
                                  > > of technical an business decisions.
                                  > > The whole team, the programmer/customer, and especially the coach,
                                  > > must be aware of which hat the programmer/customer is
                                  > wearing at any
                                  > > given time. And the coach needs to be aware that no matter how well
                                  > > the arrangement has worked I the past, if they run into
                                  > trouble, the
                                  > > dual role is a likely cause of problems."
                                  > >
                                  > > I'm not suggesting you deliberately misused the quote, but
                                  > I do think
                                  > > that something in your experience led you to read it as
                                  > absolute, when
                                  > > it's not quite so in reality.
                                  > >
                                  > > I've seen this before with folks who see XP as an absolute set of
                                  > > rules - not saying you see it that way, of course.
                                  > > They miss the signals that indicate where thought and judgement are
                                  > > needed and that misunderstanding seems to me to say more about them
                                  > > than about XP.
                                  > >
                                  > > > In the startups I've worked with, i've found it's actually pretty
                                  > > > common - you are your first customer.
                                  > > > From the sound of it though, you don't have a problem with that.
                                  > >
                                  > > No, none at all. But after 35 years I'm pretty experienced
                                  > at playing
                                  > > multiple roles and keeping my head straight about which
                                  > role I'm in at
                                  > > a given time. I often give developers cautions about trying to play
                                  > > both roles, in pretty much the same terms that Kent used in XPE1.
                                  > >
                                  > > > That's not really my view.
                                  > > > It's more, that corporate environments are the ones where I've
                                  > > > observed people actually caring whether they are "doing
                                  > XP" or not.
                                  > >
                                  > > Would that be management people, programmers or both? I'm curious.
                                  > >
                                  > > > In startups, and when I am running projects (and working
                                  > myself), I
                                  > > > don't really care, I just want the software to be
                                  > developed quickly,
                                  > > > do what it needs to do, and be confident of its quality.
                                  > > > If XP practices help, that's great, if not, who cares.
                                  > >
                                  > > That would be my position on any project - corporate IT,
                                  > application
                                  > > provider, shrinkwrap, embedded, whatever...
                                  > >
                                  > > I /believe/ that's the standard XP position as well, but I could be
                                  > > wrong. Well, not really. :-)
                                  > >
                                  > > I acknowledge that XP has at times been /read/ by some
                                  > people to mean
                                  > > something else. But they're wrong. ;-)
                                  > >
                                  > > > > What are some practices you would drop in a very small project?
                                  > > >
                                  > > >
                                  > > > The biggest one is the demarcation between Customer and
                                  > Programmer
                                  > > > roles.
                                  > > > Though from the sound of it you don't seem to believe in this
                                  > > > demarcation.
                                  > >
                                  > > For one thing, it's not a practice, not one of the twelve, but more
                                  > > like a guiding principle. I don't think you should "drop"
                                  > > it, but loosen your understanding of it a bit. "Don't try to be a
                                  > > customer and a developer without understanding the risks.
                                  > > Don't try to be both at the same moment."
                                  > >
                                  > > > Continuous Integration.
                                  > > > With a few players, just running the build when you are
                                  > finished a
                                  > > > task works better in my view.
                                  > >
                                  > > That's how it usually works. With fewer people, there are fewer
                                  > > completions and fewer checkins. Hence, fewer CI builds.
                                  > >
                                  > > > 40 hour week / sustainable pace
                                  > > > Often I find I adopt very different work patterns when totally
                                  > > > free, than the traditional working week.
                                  > > > Startups seem to give different energies than an office job.
                                  > >
                                  > > That's one reason the name was changed.
                                  > >
                                  > > > Pair programming
                                  > > > I find that often in startup mode, we don't have a
                                  > fixed location
                                  > > > and are working remotely.
                                  > >
                                  > > I haven't tried remote pairing. I imagine it would be less
                                  > satisfying
                                  > > than the real thing. But this seems to be only an accidental
                                  > > connection with startups. I know of lots of corporate settings with
                                  > > distributed teams.
                                  > >
                                  > > > Metaphor
                                  > > > I'm much more prone to Naive metaphor, though actually I never
                                  > > > really use this one.
                                  > >
                                  > > It sounds like this isn't really a size difference then. FWIW, I
                                  > > consider this one of the key practices and I don't care if Kent
                                  > > dropped it. Naïve is OK in my book if that's what you've
                                  > got. The key
                                  > > is that the whole team has a shared understanding of what you're
                                  > > doing. "Metaphor" is a metaphor for that understanding. Startups
                                  > > usually have it in spades.
                                  > >
                                  > > > Coding standards
                                  > > > Never found i've/we've needed one for 1, 2 or 3 man teams.
                                  > >
                                  > > Not needed because you all lay code out the same way and
                                  > use the same
                                  > > naming conventions without one? Or not neede because you don't mind
                                  > > variations.
                                  > >
                                  > > > Collective code ownership
                                  > > > I find "truck count" is much less of an issue in early phase
                                  > > > startups.
                                  > >
                                  > > I'm surprised at that one. Generally, its in rigid corporate
                                  > > environments that I have the most trouble with the notion that
                                  > > everyone is responsible for all the code. In startups,
                                  > that's usually
                                  > > accepted right away - IME of course.
                                  > >
                                  > > And "truck count" is only one reason for this practice.
                                  > >
                                  > > > > From the next-to-last paragraph, I'm thinking you may have run
                                  > > > > into some nominal, but not necessarily true
                                  > implementations of XP.
                                  > > > > I say that because thinking about whether you do XP is
                                  > > > generally not a
                                  > > > > good sign, even - or especially - in an XP project. The
                                  > key thing
                                  > > > > about XP is to be delivering value to the business. If
                                  > you aren't
                                  > > > > thinking about that, you can't really be doing XP.
                                  > > >
                                  > > >
                                  > > > I agree, I'm just reporting what I've observed.
                                  > > > At the current time XP (and especially "Agile") appears more
                                  > > > interesting to larger organisations.
                                  > > > Smaller ones are just getting on with it, not really calling what
                                  > > > they do XP
                                  > > > - just calling it software development.
                                  > > > Picking up practices and dropping them as they see fit.
                                  > >
                                  > > That's what most people seem to do in my experience. I've actually
                                  > > never - in a rather long career - seen programmers attempt to
                                  > > "standardize" what they do according to a methodology. That sort of
                                  > > thing has always come from above.
                                  > >
                                  > > If XP comes down from above, then the same thing is likely
                                  > to happen
                                  > > that has happened in the past. Programmers will appear to
                                  > conform to
                                  > > the extent they need to. Programmers will not really do XP.
                                  > >
                                  > > What's new with XP as compared to earlier approaches is that
                                  > > imposition of it from above is /by definition/ not XP. Agility, if
                                  > > defined in terms of results, can be successfully imposed, but XP
                                  > > cannot be imposed without becoming non-XP.
                                  > >
                                  > > > > I understand better now, although I don't agree. Your
                                  > > > description of
                                  > > > > how things work in a startup sounds much more agile to me than
                                  > > > > your description of "agile" in a corporate setting - the latter
                                  > > > > sounds decidedly unagile, in fact.
                                  > > >
                                  > > >
                                  > > > I agree.
                                  > > > Although I notice that when in startup mode, I am increasingly
                                  > > > influenced less by the standard XP/Agile views
                                  > >
                                  > > To the extent that there is a "standard" view, it's rather
                                  > fluid. XP
                                  > > teaches that we have to figure it out for each project. So
                                  > every time
                                  > > I do a project, I create yet another precise implementation of XP.
                                  > > Multiply that by thousands of people doing it. And that's not
                                  > > deviating from some ideal of XP - that /is/ XP. Frankly,
                                  > it's hard to
                                  > > get that from most books, because it's hard to write a book without
                                  > > telling people what to do.
                                  > >
                                  > > > than other viewpoints, say the Pragmatics, 37signals,
                                  > Paul Graham et
                                  > > > al, which offer similar though often subtly different
                                  > perspectives,
                                  > > > particularly with respect to the Customer / Programmer
                                  > divide, which
                                  > > > I see as a false one.
                                  > >
                                  > > I do too - but in the sense that it really isn't in XP to
                                  > the extent
                                  > > that you seem to have seen it. However, if you mean that
                                  > there need be
                                  > > no distinction at all in these two roles - not people, but roles -
                                  > > then I disagree.
                                  > >
                                  > > > And they don't often use the A-word (okay the Pragmatics do -
                                  > > > actually quite a lot) which I personally don't like.
                                  > > > Although obviously I remain an avid reader of XP list :-)
                                  > >
                                  > > Generally, as an XP guy, I don't tend to use the A word either.
                                  > > Most really experienced XP folk I know shy away from it.
                                  > > Except that customers come and ask us about it. And people come on
                                  > > this list, not noticing its name I suppose, and ask about
                                  > "agile." So
                                  > > we respond.
                                  > >
                                  > > "Agile" is too soft a word, IMO, for us to say much useful
                                  > about it,
                                  > > although I'll try if pressed. The word was coined as an
                                  > umbrella term
                                  > > to describe approaches that had some big differences, in
                                  > addition to
                                  > > their similarities. It works about as well as any such
                                  > umbrella word
                                  > > but it's quite confusing to try to talk about XP and Agile together.
                                  > >
                                  > > > Does this better clarify? or confuse?
                                  > >
                                  > > I think you're part of what I call the "Agile Backlash"
                                  > > which seems to have engaged a lot of smart people lately.
                                  > > Unfortuantely, it's not a reaction to anything particularly
                                  > agile, but
                                  > > to things that are called agile.
                                  > >
                                  > > Charlie
                                  > >
                                  > > > Cheers,
                                  > > >
                                  > > > Craig
                                  > > >
                                  > > >
                                  > > >
                                  > > > Charlie
                                  > > > >
                                  > > > > > Cheers,
                                  > > > > >
                                  > > > > > Craig
                                  > > > > >
                                  > > > > >
                                  > > > > >
                                  > > > > >
                                  > > > > >
                                  > > > > > > > For me it's a great reminder that there are many
                                  > paths to a
                                  > > > > > > > destination.
                                  > > > > > >
                                  > > > > > > Yes
                                  > > > > > >
                                  > > > > > > > And it's a great reminder to be mindfull of the
                                  > surrounding
                                  > > > > > > > constraints in those practices I do apply.
                                  > > > > > >
                                  > > > > > > Yes
                                  > > > > > >
                                  > > > > > > Charlie
                                  > > > > > >
                                  > > > > > > > Cheers
                                  > > > > > > >
                                  > > > > > > > Craig.
                                  > > > > > > >
                                  > > > > > > >
                                  > > > > > > >
                                  > > > > > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                                  > > > > > > > >
                                  > > > > > > > > Hi,
                                  > > > > > > > >
                                  > > > > > > > > This is Suresh from Chennai, India. I am a newbie to the
                                  > > > > > > > world of XP
                                  > > > > > > > > and TDD, though I am not a newbie to programming. I
                                  > > > > > just finished
                                  > > > > > > > > reading XPX:Embrace Change -- Editions 1 and 2
                                  > -- and TDD:
                                  > > > > > > > By Example
                                  > > > > > > > > back to back.
                                  > > > > > > > >
                                  > > > > > > > > Needless to say, I am thoroughly impressed with the
                                  > > > > > > > > thought
                                  > > > > > > > process,
                                  > > > > > > > > principles and values proposed by XP/TDD.
                                  > > > > > > > >
                                  > > > > > > > > Then I read this essay by Paul Graham, who is one
                                  > > > of the most
                                  > > > > > > > > respected writer/programmer around (if I am not wrong):
                                  > > > > > > > >
                                  > > > > > > > > http://www.paulgraham.com/head.html
                                  > > > > > > > >
                                  > > > > > > > > This essay, in many ways, runs against the
                                  > thought process
                                  > > > > > > > of XP/TDD.
                                  > > > > > > > > It can even be called as belonging to the "old school of
                                  > > > > > > > thought" on
                                  > > > > > > > > programming. I can actually relate to what he
                                  > says since I
                                  > > > > > > > have proved
                                  > > > > > > > > it to myself many times (programming without
                                  > distraction,
                                  > > > > > > > programming
                                  > > > > > > > > in late evening when I am alone etc.).
                                  > > > > > > > >
                                  > > > > > > > > So, I can see lots of value in what he proposes
                                  > > > (since I am a
                                  > > > > > > > > professional developer and I can see way too many
                                  > > > > > > > programmers who just
                                  > > > > > > > > can't "hold a program in their head", and I am sure
                                  > > > it is not
                                  > > > > > > > > a problem faced by Indian Software Industry alone).
                                  > > > > > > > >
                                  > > > > > > > > However, XP seems to advocate a stand that this is not
                                  > > > > > > > required, and
                                  > > > > > > > > that you can actually grow a program by concentrating
                                  > > > > > on the parts
                                  > > > > > > > > under consideration (being test driven) at any
                                  > > > point of time.
                                  > > > > > > > >
                                  > > > > > > > > Am I missing something here? Is there any real
                                  > > > overlap between
                                  > > > > > > > > what XP/TDD advocates and what Graham says (about
                                  > > > > > working alone,
                                  > > > > > > > > work in long stretches, holding the program in its
                                  > > > entirety in
                                  > > > > > > > > one's head
                                  > > > > > > > > etc.)
                                  > > > > > > > >
                                  > > > > > > > > Thanks so much.
                                  > > > > > > > >
                                  > > > > > > > > Regards,
                                  > > > > > > > > Suresh.
                                  > > > > > > > >
                                  > > > > > > > >
                                  > > > > > > > >
                                  > > > > > > > > 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
                                  > > > > > > > >
                                  > > > > > > > >
                                  > > > > > > > >
                                  > > > > > > > >
                                  > > > > > > >
                                  > > > > > > >
                                  > > > > > > > [Non-text portions of this message have been removed]
                                  > > > > > > >
                                  > > > > > > >
                                  > > > > > > >
                                  > > > > > > > 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
                                  > > > > > >
                                  > > > > > >
                                  > > > > > >
                                  > > > > > >
                                  > > > > >
                                  > > > > >
                                  > > > > > [Non-text portions of this message have been removed]
                                  > > > > >
                                  > > > > >
                                  > > > > >
                                  > > > > > 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
                                  > > > >
                                  > > > >
                                  > > > >
                                  > > > >
                                  > > >
                                  > > >
                                  > > > [Non-text portions of this message have been removed]
                                  > > >
                                  > > >
                                  > > >
                                  > > > 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
                                  > >
                                  > >
                                  > >
                                  > >
                                  >
                                  >
                                  > [Non-text portions of this message have been removed]
                                  >
                                  >
                                  >
                                  > 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
                                  >
                                  >
                                  >
                                  >
                                • William Pietri
                                  Hi, Craig. I have a lot of experience in startups, both in doing them and in coaching teams at them. I think XP works pretty well for me in those
                                  Message 16 of 25 , Sep 7, 2007
                                  • 0 Attachment
                                    Hi, Craig.

                                    I have a lot of experience in startups, both in doing them and in
                                    coaching teams at them. I think XP works pretty well for me in those
                                    circumstances. I agree you do drop some practices with small teams. A
                                    daily standup isn't so necessary for two or three people. But from the
                                    way you talk about it, I gather you and I do the planning game very
                                    differently.

                                    In my view, the XP Customer and developer roles do have both default
                                    responsibility and final authority for particular areas, but they work
                                    very closely together.

                                    As an engineer (and shareholder) I will cede final product authority to
                                    the product manger (also my partner), and they will cede final technical
                                    authority to me. But that doesn't mean that each of us isn't involved in
                                    every decision that we care about. When I'm wearing the developer hat,
                                    I'm regularly suggesting, challenging, and investigating all sorts of
                                    things on the product side. And I benefit greatly when my colleagues do
                                    the same for me about my technical decisions.

                                    In a startup it's vital that every person spend a lot of time thinking
                                    about both the product and the business. You can't afford for a
                                    developer to be just a coder, or a product manager to be just a business
                                    analyst. Everybody pulls all the weight they can. And some jobs are best
                                    done when there are checks and balances, like the ones between the XP
                                    Customer and the developers.

                                    William




                                    --
                                    William Pietri - william@... - +1-415-643-1024
                                    Agile consulting, coaching, and development: http://www.scissor.com/
                                    Instant video gratification: http://www.sidereel.com/
                                  • Craig Davidson
                                    Hi Charlie, I didn t mean to stretch what you wrote. It s just the might even bit I find interesting. Yes it s just a strategy but it is a strategy I don t
                                    Message 17 of 25 , Sep 8, 2007
                                    • 0 Attachment
                                      Hi Charlie,
                                      I didn't mean to stretch what you wrote.
                                      It's just the "might even" bit I find interesting.
                                      Yes it's just a strategy but it is a strategy I don't understand - yet.


                                      On 07/09/07, Charlie Poole <xp@...> wrote:
                                      >
                                      > Hi Craig,
                                      >
                                      > > It seems I've managed to digress onto the misapplication of
                                      > > XP in corporate environments, for that I apologise (as that
                                      > > one has been done to death I think).
                                      > >
                                      > > For me it is much less interesting than considering (non XP)
                                      > > experts (such as Paul Graham's) views of how we can go about
                                      > > building great software in small startups, Which is
                                      > > interesting to me as my default mode of development is based
                                      > > in XP practices.
                                      > >
                                      > > I think your points are all very reasonable.
                                      >
                                      > You are wise. :-)
                                      >
                                      > > The one I'm most interested in is this:
                                      > >
                                      > > "However, even if a bunch of programmers get together to
                                      > > build a company around a software product, I think it works
                                      > > better if they don't /all/ try to be the Customer all the
                                      > > time. They might even want to hire someone to take on that role."
                                      > >
                                      > >
                                      > > I've heard this recommended before,
                                      > > and I can't understand why they would want to do this (the
                                      > > hiring someone to take on the customer role part).
                                      > > It sounds very much like hiring a business analyst to me.
                                      > > Here's why...
                                      >
                                      > First of all, I said "might even" not "ought to"
                                      >
                                      > I've known many successful companies that were made so by the
                                      > hiring of a business-oriented person (not a business analyst)
                                      > who could help formulate something that can work in the market
                                      > out of the (usually) more technical vision of the engineers
                                      > who started the business.


                                      What is the difference between a business-oriented person (not a business
                                      analyst) and a business analyst.
                                      Are you thinking more of someone who will act as Marketeer, a Business
                                      Designer, or a Financial Controller.
                                      It sounds like you are taking about a Marketeer?


                                      I've known other companies that didn't need to do that. It's
                                      > just a strategy.
                                      >
                                      > Secondly, I think you're stretching what I wrote to mean more
                                      > than I intended. When I say that a person should not try
                                      > to play the customer and developer role at the same time,
                                      > I mean something like "in the same conversation" or "in the
                                      > same meeting" and not " in the same business" or "during the
                                      > same lifetime." :-)


                                      Apologies.

                                      > I've always believed that the Gold Owner and the Goal Doner
                                      > > should be as close as possible.
                                      > > (do people still use these terms?)
                                      >
                                      > Yes... at least I do. I don't know about "should" however,
                                      > since it's not something that we can normally control.


                                      We can if we are the Gold Owner....


                                      > This makes simple economic sense as it provides a basic
                                      > > differentiator between wants and needs.
                                      > > (infinite wants, limited resources, etc.)
                                      >
                                      > I don't think we can actually make rules as to who has these
                                      > roles. It just is. Someone has the money. Someone has the goals.
                                      > We can - of course - make mistakes if we create proxies for
                                      > these folks, as we often do.


                                      The smaller the organisation
                                      - especially for very small organisations the more likely the gold owner is
                                      to be the goal doner is to be the same person.
                                      At least in my experience.

                                      > For a commissioned piece of software
                                      > > (as in where someone is paying you to program) this is
                                      > > straight forward.
                                      >
                                      > Frankly, I don't find it so. The same issues of suitability
                                      > to purpose come up when one is doing work for hire. A true
                                      > professional raises those issues in that context as well.


                                      Agreed.
                                      But unless there is a legal / moral issue the final call rests the chap with
                                      the cash.


                                      > However, where the programmers are (in effect) the Gold
                                      > > Owners (through providing their time and energy), they should
                                      > > have a strong vision for the product, they should regularly
                                      > > challenge that vision themselves, and they should endeavour
                                      > > to be the first customer for their software.
                                      > > If they don't want to use it who else will?
                                      >
                                      > The only problem I have with your statements is that you don't
                                      > only seem to be applying them to a small group. In my view, this
                                      > is /exactly/ what we want in every team and it's /precisely/
                                      > what I try to achieve with XP... sometimes even with success.


                                      As I understand in this case, I am ONLY looking at a very small group.
                                      I'm not sure if this is what you mean.

                                      Second sentance is fair enough, although,
                                      the larger the project the more the likely it's subject matter is irrelevent
                                      to the programmer.
                                      I'm not saying boring -
                                      more that I am unlikely to ever be the first customer of software used by
                                      ship refit companies to manage a ship refit.


                                      Practices like pairing, shared ownership, whole team and metaphor
                                      > are all about maintenance of that strong, shared vision. Otherwise
                                      > why do them?


                                      Absolutely.

                                      I'm also a little confused about the notion that programmers are
                                      > the gold owners by virtue of providing their time and energy.
                                      > Maybe I'm not understanding the sort of environment you mean.
                                      > AFAIK, all programmers are expected to provide their time and
                                      > energy. Generally they get some compensation. One exception I
                                      > know of is in the open source world, where this issue of
                                      > customer versus programmer role can be quite difficult at times.



                                      I suspect the same, consider this simple scenario:
                                      A team of 5 very able programmers have grouped together to produce an online
                                      flowchart/diagramming tool something along the lines of say Visio- but much
                                      simpler and easier to use. They have a business model in mind that they
                                      strongly believe will work. They each agree to hold 20% of the organisation
                                      - which initially is worth nothing. They are on a shoestring budget so none
                                      of them will draw wages, will work on their own equipment and will split any
                                      technical costs equally (line/server rental, etc). With a target of a
                                      customer robust release in the 3 months time.

                                      At this point, for me, the 5 are the gold doners, they are paying from their
                                      own pocket the labour costs by not drawing wages. If the business succeeds
                                      they make money, if it fails they get no monetary reward for their efforts.

                                      As part of doing this I would expect them to have a strong enough vision to
                                      deliver a product. I would expect them to have a strong enough stake to want
                                      to be actively involved in the creation and prioritisation of stories. I
                                      expect that as time passes a product manager would emerge from the group. If
                                      they need to hire someone to tell come up with and prioritise stories, they
                                      are (in my view) doing the the wrong (or are the wrong people for) startup.

                                      And all going well, after 3 months, they should have some paying customers
                                      to provide feedback for them.

                                      Does this make sense?

                                      > When the buck stops with you
                                      > > I can't understand why you would want to offload that core
                                      > > responsibility to somebody else (and pay them for the privilege) ?
                                      >
                                      > I can't offload my responsibilities for any price. But I can pay
                                      > someone to do things that I am less skilled at or don't have time
                                      > to do. Someone in the Customer role may be the gold owner or the
                                      > goal donor, but that's not usually the case. In smaller companies
                                      > it's sometimes possible to do this


                                      It is only very small early stage startup companies I am taking about.
                                      Like the above example.


                                      > > Does this make sense? Am I misunderstanding something?
                                      >
                                      > I have a strong suspicion that we are each missing something. :-)
                                      >
                                      > I'm not sure I entirely understand the situation you are describing.
                                      > I don't think you're understanding what I mean when I stress that
                                      > one cannot generally /simultaneously/ and /successfully/ be both
                                      > implementor and customer. It's a very difficult thing to do. I
                                      > speak as one who has both done it and seen it done several times.


                                      Does my post clarify where I am coming from?

                                      Craig

                                      Charlie
                                      >
                                      > > Cheers,
                                      > >
                                      > > Craig
                                      > >
                                      > > On 07/09/07, Charlie Poole <xp@...> wrote:
                                      > > >
                                      > > > Hi Craig,
                                      > > >
                                      > > > > I think you are confusing
                                      > > > > my views on/understanding XP
                                      > > > > with my observations
                                      > > > > of how I have seen XP practiced in some organisations?
                                      > > >
                                      > > > Possibly. That's an important distinction both intellectually and
                                      > > > politically. By the latter, I mean that it's a not helpful to the
                                      > > > general state of the art if we call an inadequate of XP, "XP."
                                      > > >
                                      > > > > My understanding is that XP views it as a bad thing for people to
                                      > > > > take both developer and customer roles.
                                      > > >
                                      > > > Well, XP can't speak, but practitioners can. I'd say that most
                                      > > > situations I've seen where the same person tried to take on
                                      > > both roles
                                      > > > led to failure. This was always the programmer trying to
                                      > > take on the
                                      > > > customer role, in my experience.
                                      > > >
                                      > > > However, the underlying reason it failed doesn't apply to your
                                      > > > situation. In my observations, the programmer wasn't /really/ a
                                      > > > customer, but was just trying to play a role.
                                      > > > In your example, the programmers /really/ are customers, or
                                      > > at least
                                      > > > stakeholders, which I believe makes a world of difference.
                                      > > >
                                      > > > However, even if a bunch of programmers get together to build a
                                      > > > company around a software product, I think it works better if they
                                      > > > don't /all/ try to be the Customer all the time. They might
                                      > > even want
                                      > > > to hire someone to take on that role.
                                      > > >
                                      > > > Personally, I've worked in a few startups and I've never
                                      > > been hampered
                                      > > > from expressing my views about how the company could succeed by any
                                      > > > tenets of XP.
                                      > > >
                                      > > > > *"A programmer was also the customer. I said that
                                      > > couldn't possibly
                                      > > > > work..."
                                      > > > > XPEe1*
                                      > > >
                                      > > > Here's the follow-on to this story, one paragraph later...
                                      > > >
                                      > > > "Okay, the rules here say that a programmer can't be the
                                      > > customer. In
                                      > > > this case, the rules don't apply. What still applies is the
                                      > > separation
                                      > > > of technical an business decisions.
                                      > > > The whole team, the programmer/customer, and especially the coach,
                                      > > > must be aware of which hat the programmer/customer is
                                      > > wearing at any
                                      > > > given time. And the coach needs to be aware that no matter how well
                                      > > > the arrangement has worked I the past, if they run into
                                      > > trouble, the
                                      > > > dual role is a likely cause of problems."
                                      > > >
                                      > > > I'm not suggesting you deliberately misused the quote, but
                                      > > I do think
                                      > > > that something in your experience led you to read it as
                                      > > absolute, when
                                      > > > it's not quite so in reality.
                                      > > >
                                      > > > I've seen this before with folks who see XP as an absolute set of
                                      > > > rules - not saying you see it that way, of course.
                                      > > > They miss the signals that indicate where thought and judgement are
                                      > > > needed and that misunderstanding seems to me to say more about them
                                      > > > than about XP.
                                      > > >
                                      > > > > In the startups I've worked with, i've found it's actually pretty
                                      > > > > common - you are your first customer.
                                      > > > > From the sound of it though, you don't have a problem with that.
                                      > > >
                                      > > > No, none at all. But after 35 years I'm pretty experienced
                                      > > at playing
                                      > > > multiple roles and keeping my head straight about which
                                      > > role I'm in at
                                      > > > a given time. I often give developers cautions about trying to play
                                      > > > both roles, in pretty much the same terms that Kent used in XPE1.
                                      > > >
                                      > > > > That's not really my view.
                                      > > > > It's more, that corporate environments are the ones where I've
                                      > > > > observed people actually caring whether they are "doing
                                      > > XP" or not.
                                      > > >
                                      > > > Would that be management people, programmers or both? I'm curious.
                                      > > >
                                      > > > > In startups, and when I am running projects (and working
                                      > > myself), I
                                      > > > > don't really care, I just want the software to be
                                      > > developed quickly,
                                      > > > > do what it needs to do, and be confident of its quality.
                                      > > > > If XP practices help, that's great, if not, who cares.
                                      > > >
                                      > > > That would be my position on any project - corporate IT,
                                      > > application
                                      > > > provider, shrinkwrap, embedded, whatever...
                                      > > >
                                      > > > I /believe/ that's the standard XP position as well, but I could be
                                      > > > wrong. Well, not really. :-)
                                      > > >
                                      > > > I acknowledge that XP has at times been /read/ by some
                                      > > people to mean
                                      > > > something else. But they're wrong. ;-)
                                      > > >
                                      > > > > > What are some practices you would drop in a very small project?
                                      > > > >
                                      > > > >
                                      > > > > The biggest one is the demarcation between Customer and
                                      > > Programmer
                                      > > > > roles.
                                      > > > > Though from the sound of it you don't seem to believe in this
                                      > > > > demarcation.
                                      > > >
                                      > > > For one thing, it's not a practice, not one of the twelve, but more
                                      > > > like a guiding principle. I don't think you should "drop"
                                      > > > it, but loosen your understanding of it a bit. "Don't try to be a
                                      > > > customer and a developer without understanding the risks.
                                      > > > Don't try to be both at the same moment."
                                      > > >
                                      > > > > Continuous Integration.
                                      > > > > With a few players, just running the build when you are
                                      > > finished a
                                      > > > > task works better in my view.
                                      > > >
                                      > > > That's how it usually works. With fewer people, there are fewer
                                      > > > completions and fewer checkins. Hence, fewer CI builds.
                                      > > >
                                      > > > > 40 hour week / sustainable pace
                                      > > > > Often I find I adopt very different work patterns when totally
                                      > > > > free, than the traditional working week.
                                      > > > > Startups seem to give different energies than an office job.
                                      > > >
                                      > > > That's one reason the name was changed.
                                      > > >
                                      > > > > Pair programming
                                      > > > > I find that often in startup mode, we don't have a
                                      > > fixed location
                                      > > > > and are working remotely.
                                      > > >
                                      > > > I haven't tried remote pairing. I imagine it would be less
                                      > > satisfying
                                      > > > than the real thing. But this seems to be only an accidental
                                      > > > connection with startups. I know of lots of corporate settings with
                                      > > > distributed teams.
                                      > > >
                                      > > > > Metaphor
                                      > > > > I'm much more prone to Naive metaphor, though actually I never
                                      > > > > really use this one.
                                      > > >
                                      > > > It sounds like this isn't really a size difference then. FWIW, I
                                      > > > consider this one of the key practices and I don't care if Kent
                                      > > > dropped it. Naïve is OK in my book if that's what you've
                                      > > got. The key
                                      > > > is that the whole team has a shared understanding of what you're
                                      > > > doing. "Metaphor" is a metaphor for that understanding. Startups
                                      > > > usually have it in spades.
                                      > > >
                                      > > > > Coding standards
                                      > > > > Never found i've/we've needed one for 1, 2 or 3 man teams.
                                      > > >
                                      > > > Not needed because you all lay code out the same way and
                                      > > use the same
                                      > > > naming conventions without one? Or not neede because you don't mind
                                      > > > variations.
                                      > > >
                                      > > > > Collective code ownership
                                      > > > > I find "truck count" is much less of an issue in early phase
                                      > > > > startups.
                                      > > >
                                      > > > I'm surprised at that one. Generally, its in rigid corporate
                                      > > > environments that I have the most trouble with the notion that
                                      > > > everyone is responsible for all the code. In startups,
                                      > > that's usually
                                      > > > accepted right away - IME of course.
                                      > > >
                                      > > > And "truck count" is only one reason for this practice.
                                      > > >
                                      > > > > > From the next-to-last paragraph, I'm thinking you may have run
                                      > > > > > into some nominal, but not necessarily true
                                      > > implementations of XP.
                                      > > > > > I say that because thinking about whether you do XP is
                                      > > > > generally not a
                                      > > > > > good sign, even - or especially - in an XP project. The
                                      > > key thing
                                      > > > > > about XP is to be delivering value to the business. If
                                      > > you aren't
                                      > > > > > thinking about that, you can't really be doing XP.
                                      > > > >
                                      > > > >
                                      > > > > I agree, I'm just reporting what I've observed.
                                      > > > > At the current time XP (and especially "Agile") appears more
                                      > > > > interesting to larger organisations.
                                      > > > > Smaller ones are just getting on with it, not really calling what
                                      > > > > they do XP
                                      > > > > - just calling it software development.
                                      > > > > Picking up practices and dropping them as they see fit.
                                      > > >
                                      > > > That's what most people seem to do in my experience. I've actually
                                      > > > never - in a rather long career - seen programmers attempt to
                                      > > > "standardize" what they do according to a methodology. That sort of
                                      > > > thing has always come from above.
                                      > > >
                                      > > > If XP comes down from above, then the same thing is likely
                                      > > to happen
                                      > > > that has happened in the past. Programmers will appear to
                                      > > conform to
                                      > > > the extent they need to. Programmers will not really do XP.
                                      > > >
                                      > > > What's new with XP as compared to earlier approaches is that
                                      > > > imposition of it from above is /by definition/ not XP. Agility, if
                                      > > > defined in terms of results, can be successfully imposed, but XP
                                      > > > cannot be imposed without becoming non-XP.
                                      > > >
                                      > > > > > I understand better now, although I don't agree. Your
                                      > > > > description of
                                      > > > > > how things work in a startup sounds much more agile to me than
                                      > > > > > your description of "agile" in a corporate setting - the latter
                                      > > > > > sounds decidedly unagile, in fact.
                                      > > > >
                                      > > > >
                                      > > > > I agree.
                                      > > > > Although I notice that when in startup mode, I am increasingly
                                      > > > > influenced less by the standard XP/Agile views
                                      > > >
                                      > > > To the extent that there is a "standard" view, it's rather
                                      > > fluid. XP
                                      > > > teaches that we have to figure it out for each project. So
                                      > > every time
                                      > > > I do a project, I create yet another precise implementation of XP.
                                      > > > Multiply that by thousands of people doing it. And that's not
                                      > > > deviating from some ideal of XP - that /is/ XP. Frankly,
                                      > > it's hard to
                                      > > > get that from most books, because it's hard to write a book without
                                      > > > telling people what to do.
                                      > > >
                                      > > > > than other viewpoints, say the Pragmatics, 37signals,
                                      > > Paul Graham et
                                      > > > > al, which offer similar though often subtly different
                                      > > perspectives,
                                      > > > > particularly with respect to the Customer / Programmer
                                      > > divide, which
                                      > > > > I see as a false one.
                                      > > >
                                      > > > I do too - but in the sense that it really isn't in XP to
                                      > > the extent
                                      > > > that you seem to have seen it. However, if you mean that
                                      > > there need be
                                      > > > no distinction at all in these two roles - not people, but roles -
                                      > > > then I disagree.
                                      > > >
                                      > > > > And they don't often use the A-word (okay the Pragmatics do -
                                      > > > > actually quite a lot) which I personally don't like.
                                      > > > > Although obviously I remain an avid reader of XP list :-)
                                      > > >
                                      > > > Generally, as an XP guy, I don't tend to use the A word either.
                                      > > > Most really experienced XP folk I know shy away from it.
                                      > > > Except that customers come and ask us about it. And people come on
                                      > > > this list, not noticing its name I suppose, and ask about
                                      > > "agile." So
                                      > > > we respond.
                                      > > >
                                      > > > "Agile" is too soft a word, IMO, for us to say much useful
                                      > > about it,
                                      > > > although I'll try if pressed. The word was coined as an
                                      > > umbrella term
                                      > > > to describe approaches that had some big differences, in
                                      > > addition to
                                      > > > their similarities. It works about as well as any such
                                      > > umbrella word
                                      > > > but it's quite confusing to try to talk about XP and Agile together.
                                      > > >
                                      > > > > Does this better clarify? or confuse?
                                      > > >
                                      > > > I think you're part of what I call the "Agile Backlash"
                                      > > > which seems to have engaged a lot of smart people lately.
                                      > > > Unfortuantely, it's not a reaction to anything particularly
                                      > > agile, but
                                      > > > to things that are called agile.
                                      > > >
                                      > > > Charlie
                                      > > >
                                      > > > > Cheers,
                                      > > > >
                                      > > > > Craig
                                      > > > >
                                      > > > >
                                      > > > >
                                      > > > > Charlie
                                      > > > > >
                                      > > > > > > Cheers,
                                      > > > > > >
                                      > > > > > > Craig
                                      > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > > > > > For me it's a great reminder that there are many
                                      > > paths to a
                                      > > > > > > > > destination.
                                      > > > > > > >
                                      > > > > > > > Yes
                                      > > > > > > >
                                      > > > > > > > > And it's a great reminder to be mindfull of the
                                      > > surrounding
                                      > > > > > > > > constraints in those practices I do apply.
                                      > > > > > > >
                                      > > > > > > > Yes
                                      > > > > > > >
                                      > > > > > > > Charlie
                                      > > > > > > >
                                      > > > > > > > > Cheers
                                      > > > > > > > >
                                      > > > > > > > > Craig.
                                      > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > > On 27/08/07, protoiyer <protoiyer@...> wrote:
                                      > > > > > > > > >
                                      > > > > > > > > > Hi,
                                      > > > > > > > > >
                                      > > > > > > > > > This is Suresh from Chennai, India. I am a newbie to the
                                      > > > > > > > > world of XP
                                      > > > > > > > > > and TDD, though I am not a newbie to programming. I
                                      > > > > > > just finished
                                      > > > > > > > > > reading XPX:Embrace Change -- Editions 1 and 2
                                      > > -- and TDD:
                                      > > > > > > > > By Example
                                      > > > > > > > > > back to back.
                                      > > > > > > > > >
                                      > > > > > > > > > Needless to say, I am thoroughly impressed with the
                                      > > > > > > > > > thought
                                      > > > > > > > > process,
                                      > > > > > > > > > principles and values proposed by XP/TDD.
                                      > > > > > > > > >
                                      > > > > > > > > > Then I read this essay by Paul Graham, who is one
                                      > > > > of the most
                                      > > > > > > > > > respected writer/programmer around (if I am not wrong):
                                      > > > > > > > > >
                                      > > > > > > > > > http://www.paulgraham.com/head.html
                                      > > > > > > > > >
                                      > > > > > > > > > This essay, in many ways, runs against the
                                      > > thought process
                                      > > > > > > > > of XP/TDD.
                                      > > > > > > > > > It can even be called as belonging to the "old school of
                                      > > > > > > > > thought" on
                                      > > > > > > > > > programming. I can actually relate to what he
                                      > > says since I
                                      > > > > > > > > have proved
                                      > > > > > > > > > it to myself many times (programming without
                                      > > distraction,
                                      > > > > > > > > programming
                                      > > > > > > > > > in late evening when I am alone etc.).
                                      > > > > > > > > >
                                      > > > > > > > > > So, I can see lots of value in what he proposes
                                      > > > > (since I am a
                                      > > > > > > > > > professional developer and I can see way too many
                                      > > > > > > > > programmers who just
                                      > > > > > > > > > can't "hold a program in their head", and I am sure
                                      > > > > it is not
                                      > > > > > > > > > a problem faced by Indian Software Industry alone).
                                      > > > > > > > > >
                                      > > > > > > > > > However, XP seems to advocate a stand that this is not
                                      > > > > > > > > required, and
                                      > > > > > > > > > that you can actually grow a program by concentrating
                                      > > > > > > on the parts
                                      > > > > > > > > > under consideration (being test driven) at any
                                      > > > > point of time.
                                      > > > > > > > > >
                                      > > > > > > > > > Am I missing something here? Is there any real
                                      > > > > overlap between
                                      > > > > > > > > > what XP/TDD advocates and what Graham says (about
                                      > > > > > > working alone,
                                      > > > > > > > > > work in long stretches, holding the program in its
                                      > > > > entirety in
                                      > > > > > > > > > one's head
                                      > > > > > > > > > etc.)
                                      > > > > > > > > >
                                      > > > > > > > > > Thanks so much.
                                      > > > > > > > > >
                                      > > > > > > > > > Regards,
                                      > > > > > > > > > Suresh.
                                      > > > > > > > > >
                                      > > > > > > > > >
                                      > > > > > > > > >
                                      > > > > > > > > > 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
                                      > > > > > > > > >
                                      > > > > > > > > >
                                      > > > > > > > > >
                                      > > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > > [Non-text portions of this message have been removed]
                                      > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > >
                                      > > > > > > > > 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
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > > > [Non-text portions of this message have been removed]
                                      > > > > > >
                                      > > > > > >
                                      > > > > > >
                                      > > > > > > 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
                                      > > > > >
                                      > > > > >
                                      > > > > >
                                      > > > > >
                                      > > > >
                                      > > > >
                                      > > > > [Non-text portions of this message have been removed]
                                      > > > >
                                      > > > >
                                      > > > >
                                      > > > > 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
                                      > > >
                                      > > >
                                      > > >
                                      > > >
                                      > >
                                      > >
                                      > > [Non-text portions of this message have been removed]
                                      > >
                                      > >
                                      > >
                                      > > 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
                                      >
                                      >
                                      >
                                      >


                                      [Non-text portions of this message have been removed]
                                    • Craig Davidson
                                      Hi William, Thanks for your post, not sure if you are getting me though. ... When you have an XP Customer I agree completely. With a startup consisting of a
                                      Message 18 of 25 , Sep 8, 2007
                                      • 0 Attachment
                                        Hi William,

                                        Thanks for your post, not sure if you are getting me though.

                                        On 07/09/07, William Pietri <william@...> wrote:

                                        > Hi, Craig.
                                        >
                                        > I have a lot of experience in startups, both in doing them and in
                                        > coaching teams at them. I think XP works pretty well for me in those
                                        > circumstances. I agree you do drop some practices with small teams. A
                                        > daily standup isn't so necessary for two or three people. But from the
                                        > way you talk about it, I gather you and I do the planning game very
                                        > differently.
                                        >
                                        > In my view, the XP Customer and developer roles do have both default
                                        > responsibility and final authority for particular areas, but they work
                                        > very closely together.


                                        When you have an XP Customer I agree completely.
                                        With a startup consisting of a bunch of programmers,who is the XP Customer?
                                        Do you do you just all agree for one to be the XP Customer?


                                        > As an engineer (and shareholder) I will cede final product authority to
                                        > the product manger (also my partner), and they will cede final technical
                                        > authority to me. But that doesn't mean that each of us isn't involved in
                                        > every decision that we care about. When I'm wearing the developer hat,
                                        > I'm regularly suggesting, challenging, and investigating all sorts of
                                        > things on the product side. And I benefit greatly when my colleagues do
                                        > the same for me about my technical decisions.


                                        Definitely. Complete agreement from me here.



                                        > In a startup it's vital that every person spend a lot of time thinking
                                        > about both the product and the business. You can't afford for a
                                        > developer to be just a coder, or a product manager to be just a business
                                        > analyst. Everybody pulls all the weight they can. And some jobs are best
                                        > done when there are checks and balances, like the ones between the XP
                                        > Customer and the developers.


                                        Absolutely.
                                        I think I am in complete agreement with everything you are saying here.
                                        But my question was more around why as a small startup,
                                        If you have enough vision for a product to actually do the startup.
                                        - I still don't really get why you would employ someone to act as a proxy XP
                                        Customer?

                                        Cheers,

                                        Craig



                                        > William
                                        >
                                        >
                                        >
                                        >
                                        > --
                                        > William Pietri - william@... - +1-415-643-1024
                                        > Agile consulting, coaching, and development: http://www.scissor.com/
                                        > Instant video gratification: http://www.sidereel.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
                                        >
                                        >
                                        >
                                        >


                                        [Non-text portions of this message have been removed]
                                      • Gary Brown
                                        ... I think that a team adopting XP needs to have the support of someone in their organization who has the power to impose it, if they are going to get the
                                        Message 19 of 25 , Sep 8, 2007
                                        • 0 Attachment
                                          Quoting Charlie Poole <xp@...>:

                                          > If XP comes down from above, then the same thing is likely
                                          > to happen that has happened in the past. Programmers will
                                          > appear to conform to the extent they need to. Programmers
                                          > will not really do XP.
                                          >
                                          > What's new with XP as compared to earlier approaches is that
                                          > imposition of it from above is /by definition/ not XP. Agility,
                                          > if defined in terms of results, can be successfully imposed,
                                          > but XP cannot be imposed without becoming non-XP.
                                          >

                                          I think that a team adopting XP needs to have the support of someone
                                          in their organization who has the power to impose it, if they are
                                          going to get the full benefit. Teams rarely have the authority to
                                          hire an experienced coach, or to rearrange their workspace, on their
                                          own. Hopefully, that support won't be seen by the team as imposing XP.

                                          GB.
                                        • Charlie Poole
                                          Hi Gary, ... or at least to try to impose it... :-) ... One of the first things an outside XP coach needs to do - at least in my view of coaching - is to get
                                          Message 20 of 25 , Sep 8, 2007
                                          • 0 Attachment
                                            Hi Gary,

                                            > > If XP comes down from above, then the same thing is likely
                                            > to happen
                                            > > that has happened in the past. Programmers will appear to
                                            > conform to
                                            > > the extent they need to. Programmers will not really do XP.
                                            > >
                                            > > What's new with XP as compared to earlier approaches is that
                                            > > imposition of it from above is /by definition/ not XP. Agility, if
                                            > > defined in terms of results, can be successfully imposed, but XP
                                            > > cannot be imposed without becoming non-XP.
                                            > >
                                            >
                                            > I think that a team adopting XP needs to have the support of
                                            > someone in their organization who has the power to impose it,

                                            or at least to try to impose it... :-)

                                            > if they are going to get the full benefit. Teams rarely have
                                            > the authority to hire an experienced coach, or to rearrange
                                            > their workspace, on their own. Hopefully, that support won't
                                            > be seen by the team as imposing XP.

                                            One of the first things an outside XP coach needs to do - at least
                                            in my view of coaching - is to get the people who are paying him
                                            to give up any possibility of imposing practices and switch to
                                            demanding clearly defined results, consistent with XP. If they
                                            do that, and make it clear, the team almost always understands.

                                            On the other hand, if they just say the words, but don't hand
                                            over responsibility for actual practice to the practitioners,
                                            people understand that pretty quickly too.

                                            Charlie
                                            > GB.
                                            >
                                            >
                                            >
                                            >
                                            >
                                            > 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
                                            >
                                            >
                                            >
                                            >
                                          • Charlie Poole
                                            Hi Craig, ... FWIW, might even was meant to mean in some rare cases, one might even ... It was clear to the writer, anyway. :-) ... I was trying to write in
                                            Message 21 of 25 , Sep 8, 2007
                                            • 0 Attachment
                                              Hi Craig,

                                              > I didn't mean to stretch what you wrote.
                                              > It's just the "might even" bit I find interesting.
                                              > Yes it's just a strategy but it is a strategy I don't
                                              > understand - yet.

                                              FWIW, "might even" was meant to mean "in some rare cases,
                                              one might even"... It was clear to the writer, anyway. :-)

                                              > What is the difference between a business-oriented person
                                              > (not a business
                                              > analyst) and a business analyst.
                                              > Are you thinking more of someone who will act as Marketeer, a
                                              > Business Designer, or a Financial Controller.
                                              > It sounds like you are taking about a Marketeer?

                                              I was trying to write in very general terms, since we are not
                                              talking about any particular kind of company - or if we are,
                                              I don't know what it is. So, yes, in many companies this might
                                              be a marketing person.

                                              > > I've always believed that the Gold Owner and the Goal Doner
                                              > > > should be as close as possible.
                                              > > > (do people still use these terms?)
                                              > >
                                              > > Yes... at least I do. I don't know about "should" however, since it's
                                              > > not something that we can normally control.
                                              >
                                              > We can if we are the Gold Owner....

                                              I disagree. Of course, the fellow with the gold gets to do what he
                                              wants - that has always been so. But having the money does not
                                              necessarily mean that you are the right person, the best person
                                              to articulate the goals in a way that a team can implement them.

                                              So, let's imagine for a moment that you are the guy with the
                                              gold and - for whatever reason - you are not the best fellow
                                              to articulate the goals. Can you say "I'm gonna take on that
                                              role anyway" and make it stick? Certainly. Can you make
                                              it right, make it work successfully for the company? I'd
                                              say no: you can't change your abilities just because you
                                              want to be in control. I've seen the moneyed folks do that
                                              in several companies and it doesn't work.

                                              OTOH, if you happen to have all the right abilities in one
                                              head /plus/ the (rather rare) ability to juggle multiple,
                                              sometimes conflicting roles, then go ahead. But this is
                                              a sort of "perfect storm" situation that IMO doesn't
                                              happen very often.

                                              Unfortunately, the frequencey of people /believing/ they
                                              have all the right stuff to hold multiple roles is much
                                              higher.

                                              > > The same issues of suitability to purpose
                                              > > come up when one is doing work for hire. A true professional raises
                                              > > those issues in that context as well.
                                              >
                                              > Agreed.
                                              > But unless there is a legal / moral issue the final call
                                              > rests the chap with the cash.

                                              Technically, no. The final call rests on the guy who has
                                              decided to take the cash. He can always stop taking it.
                                              But that's another matter.

                                              > A team of 5 very able programmers have grouped together to
                                              > produce an online flowchart/diagramming tool something along
                                              > the lines of say Visio- but much simpler and easier to use.
                                              > They have a business model in mind that they strongly believe
                                              > will work. They each agree to hold 20% of the organisation
                                              > - which initially is worth nothing. They are on a shoestring
                                              > budget so none of them will draw wages, will work on their
                                              > own equipment and will split any technical costs equally
                                              > (line/server rental, etc). With a target of a customer robust
                                              > release in the 3 months time.
                                              >
                                              > At this point, for me, the 5 are the gold doners, they are
                                              > paying from their own pocket the labour costs by not drawing
                                              > wages. If the business succeeds they make money, if it fails
                                              > they get no monetary reward for their efforts.
                                              >
                                              > As part of doing this I would expect them to have a strong
                                              > enough vision to deliver a product. I would expect them to
                                              > have a strong enough stake to want to be actively involved in
                                              > the creation and prioritisation of stories. I expect that as
                                              > time passes a product manager would emerge from the group. If
                                              > they need to hire someone to tell come up with and prioritise
                                              > stories, they are (in my view) doing the the wrong (or are
                                              > the wrong people for) startup.

                                              When you say "a product manager would emerge" you are describing
                                              exactly what I'm saying needs to happen. However, in some cases,
                                              it might turn out that none of the 5 have the right skills or
                                              that none of them wants to take the time to fill that role. In
                                              that case, they might need a sixth person (who could also work
                                              for free, I suppose) with the right knowledge and skills who
                                              is willing to do the job.

                                              A lot of this depends on the domain. When programmers get together
                                              to do a programming tool, they often feel they can serve as their
                                              own customers. Even in that case, they sometimes turn out to be
                                              mistaken - by observation of many failed efforts. The farther
                                              the domain gets from their personal experience, the less likely
                                              they are to understand the market well enough to make the
                                              right decisions.

                                              > It is only very small early stage startup companies I am taking about.
                                              > Like the above example.

                                              That clarifies it somewhat - it's even earlier than what I usually hear
                                              called an "early stage startup." I'll still say that the effort will be
                                              successful to the extent that those involved actually understand the
                                              business vision as well as the product vision and the degree to which
                                              they are able to separate different types of decisions they will need
                                              to make. I've seen companies who operated as you describe without those
                                              skills and it wasn't pretty.

                                              Charlie
                                            • Gary Brown
                                              ... Agreed. Another thing that powerful person needs to do is keep the pressure off of the team for a few weeks while they learn XP. They are going to slow
                                              Message 22 of 25 , Sep 8, 2007
                                              • 0 Attachment
                                                Quoting Charlie Poole <xp@...>:

                                                > Hi Gary,
                                                >
                                                >> > If XP comes down from above, then the same thing is likely
                                                >> to happen
                                                >> > that has happened in the past. Programmers will appear to
                                                >> conform to
                                                >> > the extent they need to. Programmers will not really do XP.
                                                >> >
                                                >> > What's new with XP as compared to earlier approaches is that
                                                >> > imposition of it from above is /by definition/ not XP. Agility, if
                                                >> > defined in terms of results, can be successfully imposed, but XP
                                                >> > cannot be imposed without becoming non-XP.
                                                >> >
                                                >>
                                                >> I think that a team adopting XP needs to have the support of
                                                >> someone in their organization who has the power to impose it,
                                                >
                                                > or at least to try to impose it... :-)
                                                >
                                                >> if they are going to get the full benefit. Teams rarely have
                                                >> the authority to hire an experienced coach, or to rearrange
                                                >> their workspace, on their own. Hopefully, that support won't
                                                >> be seen by the team as imposing XP.
                                                >
                                                > One of the first things an outside XP coach needs to do - at least
                                                > in my view of coaching - is to get the people who are paying him
                                                > to give up any possibility of imposing practices and switch to
                                                > demanding clearly defined results, consistent with XP. If they
                                                > do that, and make it clear, the team almost always understands.

                                                Agreed. Another thing that powerful person needs to do is keep the
                                                pressure off of the team for a few weeks while they learn XP. They
                                                are going to slow down for a while, then get back to even, then get
                                                better. Some one looking for miracles in that first few weeks is
                                                going to be very disappointed!

                                                GB.
                                              • Charlie Poole
                                                Hi Gary, ... Absolutely. One thing I do with new clients is ask them how much productivity they are willing to give up, in days per week, for that initial
                                                Message 23 of 25 , Sep 8, 2007
                                                • 0 Attachment
                                                  Hi Gary,

                                                  > > One of the first things an outside XP coach needs to do -
                                                  > at least in
                                                  > > my view of coaching - is to get the people who are paying
                                                  > him to give
                                                  > > up any possibility of imposing practices and switch to demanding
                                                  > > clearly defined results, consistent with XP. If they do
                                                  > that, and make
                                                  > > it clear, the team almost always understands.
                                                  >
                                                  > Agreed. Another thing that powerful person needs to do is
                                                  > keep the pressure off of the team for a few weeks while they
                                                  > learn XP. They are going to slow down for a while, then get
                                                  > back to even, then get better. Some one looking for miracles
                                                  > in that first few weeks is going to be very disappointed!

                                                  Absolutely. One thing I do with new clients is ask them how much
                                                  productivity they are willing to give up, in days per week, for
                                                  that initial period. It shocks them, but for most managers it
                                                  seems to make sense after they think about it.

                                                  > GB.
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  > 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
                                                  >
                                                  >
                                                  >
                                                  >
                                                • William Pietri
                                                  Hi, Craig. I m glad to hear we re mostly on the same page. ... Three reasons. First, the product manager (which is what an XP Customer is called in my world)
                                                  Message 24 of 25 , Sep 9, 2007
                                                  • 0 Attachment
                                                    Hi, Craig. I'm glad to hear we're mostly on the same page.

                                                    Craig Davidson wrote:
                                                    > I think I am in complete agreement with everything you are saying here.
                                                    > But my question was more around why as a small startup,
                                                    > If you have enough vision for a product to actually do the startup.
                                                    > - I still don't really get why you would employ someone to act as a proxy XP
                                                    > Customer?
                                                    >

                                                    Three reasons.

                                                    First, the product manager (which is what an XP Customer is called in my
                                                    world) isn't the only source of vision, and often they're not even the
                                                    primary one. Somebody else having the vision is not a barrier.

                                                    Second, somebody has to do all the work of product management. That
                                                    includes market research, user context research, user testing, release
                                                    planning, partner coordination, writing acceptance tests, status
                                                    reporting, and so much more. That could be done by a programmer, of
                                                    course. In startups, we all do a zillion jobs at first. But we're only
                                                    expert at one or two of them. As soon as possible, it's best to hire
                                                    experts to do their thing so you can focus on yours.

                                                    And third, there is a checks-and-balances value in having somebody whose
                                                    primary focus is representing the users and maintaining a coherent
                                                    product plan. Especially in startups, where so many things are unshaped,
                                                    it is very easy to get distracted by the emergency of the moment, the
                                                    hot new trend, or the latest shiny thing. Or you can get hypnotized by
                                                    your original vision and ignore the external feedback. A steady hand on
                                                    the tiller makes for smoother sailing.


                                                    Of course, I'm not saying you have to do it, or should do it under all
                                                    circumstances. But it's sure what I'd do as soon as I could afford it.

                                                    William

                                                    --
                                                    William Pietri - william@... - +1-415-643-1024
                                                    Agile consulting, coaching, and development: http://www.scissor.com/
                                                    Instant video gratification: http://www.sidereel.com/
                                                  • Craig Davidson
                                                    Hi Charlie, William, From the last few posts it doesn t look like there is funamentally too much disagreement, if any it would be where the degree of
                                                    Message 25 of 25 , Sep 9, 2007
                                                    • 0 Attachment
                                                      Hi Charlie, William,

                                                      From the last few posts it doesn't look like there is funamentally too much
                                                      disagreement,
                                                      if any it would be where the degree of specialisation in business and
                                                      customer roles in (early stage) startups.

                                                      I think everyone's viewpoint on sounds pretty reasonable to me,
                                                      and will obviously be shaped mostly by their own experiences.

                                                      Thanks for sharing your thoughts.

                                                      Craig



                                                      On 09/09/07, William Pietri <william@...> wrote:
                                                      >
                                                      > Hi, Craig. I'm glad to hear we're mostly on the same page.
                                                      >
                                                      > Craig Davidson wrote:
                                                      > > I think I am in complete agreement with everything you are saying here.
                                                      > > But my question was more around why as a small startup,
                                                      > > If you have enough vision for a product to actually do the startup.
                                                      > > - I still don't really get why you would employ someone to act as a
                                                      > proxy XP
                                                      > > Customer?
                                                      > >
                                                      >
                                                      > Three reasons.
                                                      >
                                                      > First, the product manager (which is what an XP Customer is called in my
                                                      > world) isn't the only source of vision, and often they're not even the
                                                      > primary one. Somebody else having the vision is not a barrier.
                                                      >
                                                      > Second, somebody has to do all the work of product management. That
                                                      > includes market research, user context research, user testing, release
                                                      > planning, partner coordination, writing acceptance tests, status
                                                      > reporting, and so much more. That could be done by a programmer, of
                                                      > course. In startups, we all do a zillion jobs at first. But we're only
                                                      > expert at one or two of them. As soon as possible, it's best to hire
                                                      > experts to do their thing so you can focus on yours.
                                                      >
                                                      > And third, there is a checks-and-balances value in having somebody whose
                                                      > primary focus is representing the users and maintaining a coherent
                                                      > product plan. Especially in startups, where so many things are unshaped,
                                                      > it is very easy to get distracted by the emergency of the moment, the
                                                      > hot new trend, or the latest shiny thing. Or you can get hypnotized by
                                                      > your original vision and ignore the external feedback. A steady hand on
                                                      > the tiller makes for smoother sailing.
                                                      >
                                                      >
                                                      > Of course, I'm not saying you have to do it, or should do it under all
                                                      > circumstances. But it's sure what I'd do as soon as I could afford it.
                                                      >
                                                      > William
                                                      >
                                                      > --
                                                      > William Pietri - william@... - +1-415-643-1024
                                                      > Agile consulting, coaching, and development: http://www.scissor.com/
                                                      > Instant video gratification: http://www.sidereel.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
                                                      >
                                                      >
                                                      >
                                                      >


                                                      [Non-text portions of this message have been removed]
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.