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

Re: [XP] Paul Graham's latest essay on programming

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.