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

XP is a philosophy not a religion

Expand Messages
  • zdnfa
    Dear all, After being in the community for a couple of months I found that we are more extreme than I expected. I think that XP is a philosophy and not a
    Message 1 of 24 , Oct 28, 2009
      Dear all,
      After being in the community for a couple of months I found that we are more extreme than I expected.
      I think that XP is a philosophy and not a religion! The difference is that the first keeps developing and the other does not.
      When we first introduced the idea of developing the process of XP we had the following ideas:
      • Kent Beck said that XP does not work well with big projects (20 or more programmers). Our mission is to tune XP so that it fits any project whether small or big. We said before that in order to do that we need to adjust the method of communication used so that to emphasize more documentation in big projects and to enhance the user stories by relying on more formal analysis phase per one release, supported with signed documents (models, texts, or the like).
      • The literature is filled with the comment "tacit knowledge is more emphasized than explicit knowledge in XP" (see for example what Boehm and Turner say in this regard). We think that this is true and we need to strike a balance between the two. For example, we think that on-site customer is very important for sharing tacit knowledge, but are we sure we will find a full time customer who is able to answer all types of questions especially in big projects. (We used the modified XP (i.e. introducing an analysis phase per one release and using more documentations than just relying on code and test cases) in developing a tax system for a country that has little experience in IT and taxation, which means more BPR, new decrees, new structures and so on. Do you think using coding standards and test cases only would work?
      • There were a couple of attempts to modify XP for such situations, such as what Menzo did in his Code Science, XPRINCE2 of Nawrocki, and Martin's dx.
      The surprise for us was not rejecting our ideas, but the way they were rejected. We are not saying our ideas are correct –not at all- but the comments we got, such as describing Kent as a positivist just for welcoming our trial and questioning its applicability.
      For a newcomer to the community, this was a shock and really frustrated me
    • Bill Caputo
      ... That includes me I suppose... ... I came to the opposite conclusion a good while ago: http://www.williamcaputo.com/archives/000070.html ... Completely
      Message 2 of 24 , Oct 28, 2009
        On Wed, Oct 28, 2009 at 3:53 AM, zdnfa <zdnfa@...> wrote:
        > Dear all,
        That includes me I suppose...

        > I think that XP is a philosophy and not a religion!

        I came to the opposite conclusion a good while ago:
        http://www.williamcaputo.com/archives/000070.html

        >The difference is that the first keeps developing and the other does not.

        Completely disagree -- the difference is one of semantics at best. My
        guess is Wittgenstein would've said the distinction is meaningless as
        their definitions are so vague. Dogmatism exists in all social
        endeavors - if I find one of those terms less pejorative it says more
        about my biases than about any objective distinction between them.

        > The surprise for us was not rejecting our ideas, but the way they were rejected. We are not saying our ideas are correct –not at all- but the comments we got, such as describing Kent as a positivist just for welcoming our trial and questioning its applicability.
        > For a newcomer to the community, this was a shock and really frustrated me

        And so we come to the real issue: Whether religion or philosophy,
        science or social club, the one thing that is constant is that people
        tend to reject the novel -- especially from a new source. Being new to
        any club means having to overcome resistance whether its philosophy
        club, chess club, physics club or XP club - pushing new ideas at the
        same time will get you labelled 'outsider' faster than you can say
        'cold fusion.'

        But don't get discouraged. I'd say you're right on track. Your next
        step is to decide whether the club is worth sticking with to get your
        ideas across - and if so, to keep engaging, listening and becoming
        part of the regulars. But if you choose not to, don't blame the
        dogmatists - they're in every club, so its really about your desire
        for social acceptance (and all the crap that goes with it) than it is
        about XP's adherents.

        In short: Welcome to the people club. :-)

        Best,
        Bill
      • Chris Morris
        ... step is to decide whether the club is worth sticking with to get your ideas across - and if so, to keep engaging, listening and becoming part of the
        Message 3 of 24 , Oct 28, 2009
          >
          > But don't get discouraged. I'd say you're right on track. Your next

          step is to decide whether the club is worth sticking with to get your

          ideas across - and if so, to keep engaging, listening and becoming

          part of the regulars. But if you choose not to, don't blame the

          dogmatists - they're in every club, so its really about your desire

          for social acceptance (and all the crap that goes with it) than it is

          about XP's adherents.


          > In short: Welcome to the people club. :-)



          +5

          --
          Chris
          http://clabs.org


          [Non-text portions of this message have been removed]
        • Steven Gordon
          Sorry, but my reaction to the ideas you have espoused are not changed at all by your shock and frustration, nor by your reasoning. XP is a process that was
          Message 4 of 24 , Oct 28, 2009
            Sorry, but my reaction to the ideas you have espoused are not changed at all
            by your shock and frustration, nor by your reasoning.

            XP is a process that was developed empirically from trail and error on
            actual projects. It does continue to change empirically, based on
            experience applying it to more projects in more contexts and the adjustments
            that proved to work in practice. A top-down redesign by theorists (rather
            than by practitioners trying to apply XP in new contexts) creates a totally
            new process, not a new XP.

            If you do not insist on calling this new process XP or an improved XP, you
            will get much less resistance here, and probably any place that either loves
            or hates XP.

            If you would then reflect on how this new process works, not based on
            knowledge theories, but on experience on actual software development
            projects (including adjustments made by practioners during those
            experiences), then we can have an honest dialog about how agile and
            effective this new process turns out to be in practice.

            You should welcome the skepticism because it will improve your ideas and it
            will tell you when they are actually ready.

            Steven Gordon, PhD

            On Wed, Oct 28, 2009 at 1:53 AM, zdnfa <zdnfa@...> wrote:

            >
            >
            > Dear all,
            > After being in the community for a couple of months I found that we are
            > more extreme than I expected.
            > I think that XP is a philosophy and not a religion! The difference is that
            > the first keeps developing and the other does not.
            > When we first introduced the idea of developing the process of XP we had
            > the following ideas:
            > � Kent Beck said that XP does not work well with big projects (20 or more
            > programmers). Our mission is to tune XP so that it fits any project whether
            > small or big. We said before that in order to do that we need to adjust the
            > method of communication used so that to emphasize more documentation in big
            > projects and to enhance the user stories by relying on more formal analysis
            > phase per one release, supported with signed documents (models, texts, or
            > the like).
            > � The literature is filled with the comment "tacit knowledge is more
            > emphasized than explicit knowledge in XP" (see for example what Boehm and
            > Turner say in this regard). We think that this is true and we need to strike
            > a balance between the two. For example, we think that on-site customer is
            > very important for sharing tacit knowledge, but are we sure we will find a
            > full time customer who is able to answer all types of questions especially
            > in big projects. (We used the modified XP (i.e. introducing an analysis
            > phase per one release and using more documentations than just relying on
            > code and test cases) in developing a tax system for a country that has
            > little experience in IT and taxation, which means more BPR, new decrees, new
            > structures and so on. Do you think using coding standards and test cases
            > only would work?
            > � There were a couple of attempts to modify XP for such situations, such as
            > what Menzo did in his Code Science, XPRINCE2 of Nawrocki, and Martin's dx.
            > The surprise for us was not rejecting our ideas, but the way they were
            > rejected. We are not saying our ideas are correct �not at all- but the
            > comments we got, such as describing Kent as a positivist just for welcoming
            > our trial and questioning its applicability.
            > For a newcomer to the community, this was a shock and really frustrated me
            >
            >
            >
            >


            [Non-text portions of this message have been removed]
          • Adam Sroka
            I am sorry if your feelings were hurt. I don t think that was anyone s intention and it certainly wasn t mine. The nature of this medium is that it is
            Message 5 of 24 , Oct 28, 2009
              I am sorry if your feelings were hurt. I don't think that was anyone's
              intention and it certainly wasn't mine. The nature of this medium is
              that it is relatively easy to be brutal when we only mean to be
              honest.

              Kent's response to you was that if this was an area of inquiry you
              were interested in you should go for it. Maybe you will find
              something, and when you do you can share it with us. That is perfectly
              reasonable.

              My response was that I think you are missing the point, and because I
              think you are missing the point it would be irresponsible of me not to
              let you know that. I think that I have already been down the road you
              are describing, and I found it to be a dead end. I'm not going to tell
              you not to go there, but I am going to tell you that when I did I
              found a dead end.

              Hurt feelings or not I still have a fundamental problem with your
              premise: XP does not work well with big teams. Therefore we should
              modify XP so that it works with big teams. The way to do this is to
              replace some face-to-face communication with documentation and
              exploratory design with detailed analysis.

              1) It is not obvious to me that being able to work with larger teams
              is in-and-of-itself an advantage. Why do we need larger teams? What is
              the intrinsic benefit of a large team?

              2) Maybe the reason that XP works is that it favors one kind of
              communication over the other. Maybe there is a reason that
              "Communication" is explicitly a core value of XP. Maybe there is a
              reason that the folks at Snowbird called out "Individuals and
              Interactions over processes and tools," and, "Working Software over
              comprehensive documentation." Perhaps they actually tried doing the
              things on the right and felt that they didn't work as well as the
              things on the left.

              3) More to the point, I have been on projects that did the things you
              suggest and they didn't help. I have seen small teams manage to
              deliver what a much larger team had already failed to defying all
              conventional wisdom about "resource management."

              Some of us have already been to where you want to go. If you want to
              go there, fine, but it doesn't make us zealots because we continue in
              the opposite direction. It also doesn't make us zealots to suggest
              that you won't find what you are looking for where we have already
              been. Neither does it mean you can't or shouldn't go there.

              On Wed, Oct 28, 2009 at 1:53 AM, zdnfa <zdnfa@...> wrote:
              >
              >
              >
              > Dear all,
              > After being in the community for a couple of months I found that we are more extreme than I expected.
              > I think that XP is a philosophy and not a religion! The difference is that the first keeps developing and the other does not.
              > When we first introduced the idea of developing the process of XP we had the following ideas:
              > • Kent Beck said that XP does not work well with big projects (20 or more programmers). Our mission is to tune XP so that it fits any project whether small or big. We said before that in order to do that we need to adjust the method of communication used so that to emphasize more documentation in big projects and to enhance the user stories by relying on more formal analysis phase per one release, supported with signed documents (models, texts, or the like).
              > • The literature is filled with the comment "tacit knowledge is more emphasized than explicit knowledge in XP" (see for example what Boehm and Turner say in this regard). We think that this is true and we need to strike a balance between the two. For example, we think that on-site customer is very important for sharing tacit knowledge, but are we sure we will find a full time customer who is able to answer all types of questions especially in big projects. (We used the modified XP (i.e. introducing an analysis phase per one release and using more documentations than just relying on code and test cases) in developing a tax system for a country that has little experience in IT and taxation, which means more BPR, new decrees, new structures and so on. Do you think using coding standards and test cases only would work?
              > • There were a couple of attempts to modify XP for such situations, such as what Menzo did in his Code Science, XPRINCE2 of Nawrocki, and Martin's dx.
              > The surprise for us was not rejecting our ideas, but the way they were rejected. We are not saying our ideas are correct –not at all- but the comments we got, such as describing Kent as a positivist just for welcoming our trial and questioning its applicability.
              > For a newcomer to the community, this was a shock and really frustrated me
              >
              >
            • Curtis Cooley
              ... I ve always thought there has to be an Amdahl s Law* for software development. Just as there is a limit to how many processors you can add before
              Message 6 of 24 , Oct 28, 2009
                On Wed, Oct 28, 2009 at 10:48 AM, Adam Sroka <adam.sroka@...> wrote:
                > 1) It is not obvious to me that being able to work with larger teams
                > is in-and-of-itself an advantage. Why do we need larger teams? What is
                > the intrinsic benefit of a large team?
                >
                I've always thought there has to be an Amdahl's Law* for software
                development. Just as there is a limit to how many processors you can
                add before communication overhead starts to impede performance, there
                has to be a limit to how many developers can effectively work on a
                system. The question is, is that limit 10, 100, 1,000, 1,000,000? I
                have no evidence but my own experience, and I tend to think the limit
                is lower than we think and many projects are actually working over the
                limit. I can't remember where I heard him say it, possibly Chicago in
                2002, but Kent once said "In every 100 person team there's a 10 man XP
                team trying to get out." Couldn't have said it better myself.

                So the question changes from how do I get XP to work with my 1000
                person team to how many XP programmers can do what my 1000 person team
                now does. My guess is about 10.

                > 2) Maybe the reason that XP works is that it favors one kind of
                > communication over the other. Maybe there is a reason that
                > "Communication" is explicitly a core value of XP. Maybe there is a
                > reason that the folks at Snowbird called out "Individuals and
                > Interactions over processes and tools," and, "Working Software over
                > comprehensive documentation." Perhaps they actually tried doing the
                > things on the right and felt that they didn't work as well as the
                > things on the left.
                >
                Again we are back to Amdahl's Law* because it all comes down to
                communication. Formalizing communication will only clog its flow, not
                enhance it, making Amdahl's Law* even more apropos.

                > 3) More to the point, I have been on projects that did the things you
                > suggest and they didn't help. I have seen small teams manage to
                > deliver what a much larger team had already failed to defying all
                > conventional wisdom about "resource management."
                >
                That's what I said ;)

                * Amdahl's Law: http://en.wikipedia.org/wiki/Amdahl's_law
                --
                Curtis Cooley
                curtis.cooley@...
                home:http://curtiscooley.com
                blog:http://ponderingobjectorienteddesign.blogspot.com
                ===============
                Leadership is a potent combination of strategy and character. But if
                you must be without one, be without the strategy.
                -- H. Norman Schwarzkopf
              • Ron Jeffries
                Hello, zdnfa. On Wednesday, October 28, 2009, at 4:53:07 AM, you ... Excellent ... ... I m not sure I agree with the distinction, but certainly XP and our
                Message 7 of 24 , Oct 29, 2009
                  Hello, zdnfa. On Wednesday, October 28, 2009, at 4:53:07 AM, you
                  wrote:

                  > After being in the community for a couple of months I found that
                  > we are more extreme than I expected.

                  Excellent ...

                  > I think that XP is a philosophy and not a religion! The
                  > difference is that the first keeps developing and the other does not.

                  I'm not sure I agree with the distinction, but certainly XP and our
                  understanding of it keeps developing.

                  > When we first introduced the idea of developing the process of XP
                  > we had the following ideas:

                  > • Kent Beck said that XP does not work well with big
                  > projects (20 or more programmers).

                  > Our mission is to tune XP so that it fits any project whether
                  > small or big. We said before that in order to do that we need to
                  > adjust the method of communication used so that to emphasize more
                  > documentation in big projects and to enhance the user stories by
                  > relying on more formal analysis phase per one release, supported
                  > with signed documents (models, texts, or the like).

                  Nothing works as well with large projects as it does with small
                  ones. I see no reason why a large project couldn't add more
                  documents if it chose to, other than the well known fact that
                  written material loses a high percentage of understanding compared
                  to face to face discussion.

                  I also see no reason why one would call such a process "XP". If I
                  were looking for some kind of pluggable / tunable process, I would
                  consider Crystal by Alistair Cockburn, which is set up to be scaled.

                  I'm not looking for such a thing, personally. I think that each
                  project does need to have a process fitted to it but I also think
                  that every element added to a written process begins to burden all
                  instances.

                  Suppose that "XP" called for "written documents for large projects".
                  Some reason would be offered. Then, anyone considering XP would find
                  themselves in a position of having to take a chance on doing what XP
                  actually recommends, instead of adding in all the bits for "large"
                  projects. That would, in my opinion, be bad.

                  > • The literature is filled with the comment "tacit knowledge is
                  > more emphasized than explicit knowledge in XP" (see for example
                  > what Boehm and Turner say in this regard).

                  The literature is emphatically not filled with that comment. It does
                  appear sometimes. What is emphasized in XP is communication.
                  Common knowledge is the result of communication.

                  > We think that this is true and we need to strike a balance between
                  > the two. For example, we think that on-site customer is very
                  > important for sharing tacit knowledge, but are we sure we will
                  > find a full time customer who is able to answer all types of
                  > questions especially in big projects.

                  XP says to have one. If a team doesn't have one, the team is not
                  doing what XP recommends.

                  > (We used the modified XP
                  > (i.e. introducing an analysis phase per one release and using more
                  > documentations than just relying on code and test cases) in
                  > developing a tax system for a country that has little experience
                  > in IT and taxation, which means more BPR, new decrees, new
                  > structures and so on.

                  There is no "authorized" modification of XP with this "phase", so
                  far as I know.

                  > Do you think using coding standards and test
                  > cases only would work?

                  I think it would work better than some process that assumed from the
                  outset that they would not work. I think a team working with those
                  practices, and the other XP practices, would /discover/ what specific
                  other materials /that specific team/ needed. Legislating those
                  matters cannot be better than choosing things that are actually
                  found to be needed.

                  > • There were a couple of attempts to modify
                  > XP for such situations, such as what Menzo did in his Code
                  > Science, XPRINCE2 of Nawrocki, and Martin's dx.

                  The success of the first two speaks for itself. Martin's dx, as far
                  as I know, was not substantially different from XP. It was a cute
                  naming trick and little more.

                  > The surprise for
                  > us was not rejecting our ideas, but the way they were rejected. We
                  > are not saying our ideas are correct –not at all- but the comments
                  > we got, such as describing Kent as a positivist just for welcoming
                  > our trial and questioning its applicability. For a newcomer to the
                  > community, this was a shock and really frustrated me

                  Why are you shocked and frustrated by someone's description of Kent,
                  if in fact anyone described Kent as a positivist?

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  Computers are useless. They can only give you answers. -- Picasso
                • zdnfa
                  Communication has to be emphasized, no doubt! face-to-face communication is the best, no doubt! But what if it is too difficult to do so? What if we are in an
                  Message 8 of 24 , Oct 29, 2009
                    Communication has to be emphasized, no doubt! face-to-face communication is the best, no doubt! But what if it is too difficult to do so? What if we are in an environment whereb we have to work with some remote teams? What if we need the knowledge of many on-site customers in order to have a comprehensive view of the system? what if customers' business really hinders communication?

                    talking about face to face communicaiton only means focusing on tacit knowledge, which is problematic with employee turnover. Moreover this tacit knowledge is subjective, and volatile and we need one that is objective and maintainable. Do you get my point?
                  • Adam Sroka
                    I get your point, and everything you said is true. However, XP doesn t have any of these problems, because XP has the courage to say that the team should be
                    Message 9 of 24 , Oct 29, 2009
                      I get your point, and everything you said is true. However, XP doesn't
                      have any of these problems, because XP has the courage to say that the
                      team should be small, should sit together, and should function as a
                      working whole.

                      What XP says to do isn't feasible for every project, every team, or
                      every organization. However, it does not follow that XP should
                      recommend something else in order to become a one size fits all
                      solution. Further, none of the changes you are recommending are novel.
                      They simply aren't part of XP by design.

                      On Thu, Oct 29, 2009 at 8:28 PM, zdnfa <zdnfa@...> wrote:
                      >
                      >
                      >
                      > Communication has to be emphasized, no doubt! face-to-face communication is the best, no doubt! But what if it is too difficult to do so? What if we are in an environment whereb we have to work with some remote teams? What if we need the knowledge of many on-site customers in order to have a comprehensive view of the system? what if customers' business really hinders communication?
                      >
                      > talking about face to face communicaiton only means focusing on tacit knowledge, which is problematic with employee turnover. Moreover this tacit knowledge is subjective, and volatile and we need one that is objective and maintainable. Do you get my point?
                      >
                      >
                    • Steven Gordon
                      In other words, if you have those obstructions to XP and cannot (or choose not to) remove those obstructions, then do not use XP. What should you use in such
                      Message 10 of 24 , Oct 29, 2009
                        In other words, if you have those obstructions to XP and cannot (or choose
                        not to) remove those obstructions, then do not use XP.

                        What should you use in such cases? You could use what you propose, but that
                        does not make what you propose be an improvement on XP - it is just a
                        different process for a different context.

                        You quoted Boehm and Turner. They have a n-dimensional space for describing
                        processes (I cannot recall whether n = 5 or = 6). What you propose is at a
                        different location in that space than XP is. So be it. Why do you have to
                        move XP's location in Boehm-Turner space in order to justify your idea?

                        On Thu, Oct 29, 2009 at 8:34 PM, Adam Sroka <adam.sroka@...> wrote:

                        >
                        >
                        > I get your point, and everything you said is true. However, XP doesn't
                        > have any of these problems, because XP has the courage to say that the
                        > team should be small, should sit together, and should function as a
                        > working whole.
                        >
                        > What XP says to do isn't feasible for every project, every team, or
                        > every organization. However, it does not follow that XP should
                        > recommend something else in order to become a one size fits all
                        > solution. Further, none of the changes you are recommending are novel.
                        > They simply aren't part of XP by design.
                        >
                        >
                        > On Thu, Oct 29, 2009 at 8:28 PM, zdnfa <zdnfa@...<zdnfa%40yahoo.com>>
                        > wrote:
                        > >
                        > >
                        > >
                        > > Communication has to be emphasized, no doubt! face-to-face communication
                        > is the best, no doubt! But what if it is too difficult to do so? What if we
                        > are in an environment whereb we have to work with some remote teams? What if
                        > we need the knowledge of many on-site customers in order to have a
                        > comprehensive view of the system? what if customers' business really hinders
                        > communication?
                        > >
                        > > talking about face to face communicaiton only means focusing on tacit
                        > knowledge, which is problematic with employee turnover. Moreover this tacit
                        > knowledge is subjective, and volatile and we need one that is objective and
                        > maintainable. Do you get my point?
                        > >
                        > >
                        >
                        >
                        >


                        [Non-text portions of this message have been removed]
                      • zdnfa
                        ... OK let try this: 1. The lifecycle we are suggesting is this: analysis( one phase per release)plan for the releasequick designcodingrelease. Not
                        Message 11 of 24 , Oct 30, 2009
                          --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                          >
                          > I get your point, and everything you said is true. However, XP doesn't
                          > have any of these problems, because XP has the courage to say that the
                          > team should be small, should sit together, and should function as a
                          > working whole.
                          >
                          > What XP says to do isn't feasible for every project, every team, or
                          > every organization. However, it does not follow that XP should
                          > recommend something else in order to become a one size fits all
                          > solution. Further, none of the changes you are recommending are novel.
                          > They simply aren't part of XP by design.


                          OK let try this:

                          1. The lifecycle we are suggesting is this: analysis( one phase per release)plan for the releasequick designcodingrelease. Not every project requires an analysis phase, hence start by evaluating the project environment and see if it is well structured and you don't need this phase or otherwise. This is just a minor change to XP lifecycle.
                          2. If you need this analysis phase then make your team as team of teams and let every pair do the analysis and we call this pair development rather than pair programming.
                          3. In large projects, where you need to communicate with the customer in a formal manner, use models that are understandable for naïve customers such as swim lane diagram. (we had to develop a tax system for a country that is passing through drastic reform and this model was superior)
                          4. Keep coding standards and have no mercy in this regard. Use continuous integration and have no mercy in this regard too. Use automated tests, and have no mercy here too. Use on-site-customer in the team structure: if she will not answer all your questions she'll be able to form the questions in a better way. Etc.
                          So we still call ourselves XP'ers, and we want to remain so and for every project.

                          Regards
                          zaidoun
                        • Ron Jeffries
                          Hello, zdnfa. On Thursday, October 29, 2009, at 11:28:08 PM, you ... Then these things need to be corrected, and compensated for in a fashion that fits the
                          Message 12 of 24 , Oct 30, 2009
                            Hello, zdnfa. On Thursday, October 29, 2009, at 11:28:08 PM, you
                            wrote:

                            > Communication has to be emphasized, no doubt! face-to-face
                            > communication is the best, no doubt! But what if it is too
                            > difficult to do so? What if we are in an environment whereb we
                            > have to work with some remote teams? What if we need the knowledge
                            > of many on-site customers in order to have a comprehensive view of
                            > the system? what if customers' business really hinders communication?

                            Then these things need to be corrected, and compensated for in a
                            fashion that fits the exact situation. They do not call for a change
                            to the fundamentals of XP.

                            > talking about face to face communicaiton only means focusing on
                            > tacit knowledge, which is problematic with employee turnover.
                            > Moreover this tacit knowledge is subjective, and volatile and we
                            > need one that is objective and maintainable. Do you get my point?

                            Tacit knowledge is actually the only knowledge that leads to correct
                            action. Objective knowledge, if such a thing exists at all, is
                            passive and dead. Our job is to get the right tacit knowledge into
                            the heads of those who need it. Written material is one way to do
                            this, but not a very good one.

                            I don't know whether I get your point or not.

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            Ron gave me a good suggestion once. -- Carlton (banshee858)
                          • Critique
                            Hi there, I think the core of the problem in this thread is one of purity , ... It s understandable that anyone on this list has an interest in learning about
                            Message 13 of 24 , Oct 30, 2009
                              Hi there,

                              I think the core of the problem in this thread is one of "purity",
                              classification, and in particular this:

                              > So we still call ourselves XP'ers, and we want to remain so and for every project.

                              It's understandable that anyone on this list has an interest in
                              learning about XP and taking what lessons they can from it and
                              discussions of it.

                              But what is "using XP"? A "pure" classification would be "following
                              100% of the rules of XP".

                              But what if I'm trying to use XP and can only make use of 95% of the
                              rules for good reasons A, B and C? Am I using XP? From the "pure"
                              classification above, no I'm not, but you could say "I'm using as much
                              XP as I can, and adapting it. It's still 95% XP and so I still call it
                              XP." And for 5% many people are likely to either miss the
                              differences, or to agree that, on balance, you are probably using XP
                              more than not and it's okay to call it XP.

                              But what about if I'm using 80% XP? 70%? 51%? At some point,
                              differing from person to person, I will stop "using XP". Maybe I
                              *want* to, maybe I'm *trying* to, and maybe from my point of view I
                              *am* even though to another point of view I'm *not*.

                              It's understandably frustrating that at 75%, or whatever value you
                              wish to assign, you are - from your point of view - and want to be
                              considered to be using XP. But other people have a limit of 80% and
                              so, from their point of view, you're not. We're people - we're not
                              going to get everyone to agree because we all have different
                              experiences and opinions.

                              The line is fuzzy; all lines are. Rather than arguing about where the
                              line is I want to know what challenges and approaches are being seen
                              all throughout the line - and what problems are percieved and the
                              experience behind those perceptions - from 0% XP (probably not on this
                              list) to 100% XP so I can take it away and use it where I think it's
                              relevant and where I can. Maybe I'm only using 5% XP - certainly I'm
                              not using 100% because in my current circumstances it's impossible for
                              me to do so. It doesn't matter, that's not what this list is here for,
                              in my understanding, which is the discussion of XP practices,
                              challenges, and experiences.

                              So call yourselves XP'ers, XP-varianters, or whatever you like, but
                              don't expect that other people will, or even necessarily should,
                              categorise you in the same way. It doesn't matter what the label is,
                              someone will disagree with it. That doesn't invalidate your ideas and
                              experience - or theirs. Aren't we all here to learn from each other?
                              Put yourself in the other person's shoes - chances are they're not
                              intending to have a go at you, just to share their view.

                              And that does work both ways; consider how your responses to something
                              are likely to be interpreted. It's empathy, and without it there is no
                              good communication. And as we, devotees of XP all, can hopefully
                              agree: good communication is vital.

                              Jon
                            • Ilja Preuß
                              Why is it important to you to call what you are doing XP ? Curious, Ilja
                              Message 14 of 24 , Oct 30, 2009
                                Why is it important to you to call what you are doing "XP"?

                                Curious, Ilja

                                2009/10/30 zdnfa <zdnfa@...>:
                                >
                                >
                                > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                >>
                                >> I get your point, and everything you said is true. However, XP doesn't
                                >> have any of these problems, because XP has the courage to say that the
                                >> team should be small, should sit together, and should function as a
                                >> working whole.
                                >>
                                >> What XP says to do isn't feasible for every project, every team, or
                                >> every organization. However, it does not follow that XP should
                                >> recommend something else in order to become a one size fits all
                                >> solution. Further, none of the changes you are recommending are novel.
                                >> They simply aren't part of XP by design.
                                >
                                >
                                > OK let try this:
                                >
                                > 1.      The lifecycle we are suggesting is this: analysis( one phase per release)plan for the releasequick designcodingrelease. Not every project requires an analysis phase, hence start by evaluating the project environment and see if it is well structured and you don't need this phase or otherwise. This is just a minor change to XP lifecycle.
                                > 2.      If you need this analysis phase then make your team as team of teams and let every pair do the analysis and we call this pair development rather than pair programming.
                                > 3.      In large projects, where you need to communicate with the customer in a formal manner, use models that are understandable for naïve customers such as swim lane diagram. (we had to develop a tax system for a country that is passing through drastic reform and this model was superior)
                                > 4.      Keep coding standards and have no mercy in this regard. Use continuous integration and have no mercy in this regard too. Use automated tests, and have no mercy here too. Use on-site-customer in the team structure: if she will not answer all your questions she'll be able to form the questions in a better way. Etc.
                                > So we still call ourselves XP'ers, and we want to remain so and for every project.
                                >
                                > Regards
                                > zaidoun
                                >
                                >
                                >
                                >
                                > ------------------------------------
                                >
                                > To Post a message, send it to:   extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                >
                                > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                >
                                >
                                >
                                >
                              • Steven Gordon
                                ... I think you do not appreciate the impact to this change to the XP lifecycle. If the pre-analysis is detailed, it will either make change expensive or have
                                Message 15 of 24 , Oct 30, 2009
                                  On Fri, Oct 30, 2009 at 3:44 AM, zdnfa <zdnfa@...> wrote:
                                  >
                                  >
                                  >
                                  > --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                  > >
                                  > > I get your point, and everything you said is true. However, XP doesn't
                                  > > have any of these problems, because XP has the courage to say that the
                                  > > team should be small, should sit together, and should function as a
                                  > > working whole.
                                  > >
                                  > > What XP says to do isn't feasible for every project, every team, or
                                  > > every organization. However, it does not follow that XP should
                                  > > recommend something else in order to become a one size fits all
                                  > > solution. Further, none of the changes you are recommending are novel.
                                  > > They simply aren't part of XP by design.
                                  >
                                  > OK let try this:
                                  >
                                  > 1. The lifecycle we are suggesting is this: analysis( one phase per release)plan for the releasequick designcodingrelease. Not every project requires an analysis phase, hence start by evaluating the project environment and see if it is well structured and you don't need this phase or otherwise. This is just a minor change to XP lifecycle.

                                  I think you do not appreciate the impact to this change to the XP
                                  lifecycle. If the pre-analysis is detailed, it will either make
                                  change expensive or have be followed only very loosely when
                                  developing. If the pre-analysis is just at the domain level, then it
                                  is not a change to XP at all.

                                  > 2. If you need this analysis phase then make your team as team of teams and let every pair do the analysis and we call this pair development rather than pair programming.

                                  Pair programming is a misnomer. It really is pair development because
                                  it is really a seamless integration of requirement gathering,
                                  analysis, design, testing and implementation.

                                  The key is that just enough of each activity is done when needed,
                                  rather than doing all the requirement gathering and analysis weeks
                                  before doing the rest. When the detailed requirement and analysis
                                  work comes weeks ahead of the rest, then things have to be documented
                                  in detail so they are not forgotten, but then they are inevitably
                                  misunderstood. By doing it all at once for small feature slices, it
                                  can all be accomplished while everybody involved has the same
                                  understanding and without the overhead of detailed design
                                  documentation.

                                  > 3. In large projects, where you need to communicate with the customer in a formal manner, use models that are understandable for naïve customers such as swim lane diagram. (we had to develop a tax system for a country that is passing through drastic reform and this model was superior)

                                  There is still large risk of miscommunication and misunderstanding.
                                  Also, when in the midst of iterative delivery and feedback, it is
                                  discovered that what was documented does not work well or a better
                                  idea occurs to somebody, the cost of change has increased
                                  significantly.

                                  > 4. Keep coding standards and have no mercy in this regard. Use continuous integration and have no mercy in this regard too. Use automated tests, and have no mercy here too. Use on-site-customer in the team structure: if she will not answer all your questions she'll be able to form the questions in a better way. Etc.

                                  XP is more than just the engineering practices.

                                  There is nothing that prevents a team from following the engineering
                                  practices under waterfall or any other process. What makes XP agile
                                  is that we do these practices in order to facilitate short feedback
                                  loops and low cost of change.

                                  Substituting formal documentation for the short feedback loops and low
                                  cost of change significantly reduces agility. It does not mean you
                                  cannot do XP's engineering practices, it just means you won't be doing
                                  agile software development.

                                  > So we still call ourselves XP'ers, and we want to remain so and for every project.

                                  >
                                  > Regards
                                  > zaidoun
                                  >
                                • kentb
                                  Zaidoun, The process you process seems reasonable to me. If you tried to shrink the deployment cycle further you might need new or different practices, but
                                  Message 16 of 24 , Oct 30, 2009
                                    Zaidoun,

                                    The process you process seems reasonable to me. If you tried to shrink the
                                    deployment cycle further you might need new or different practices, but what
                                    you've outlined could support accountability and transparency. I hope you
                                    will let us know how it goes.

                                    Regards,

                                    Kent

                                    _____

                                    From: extremeprogramming@yahoogroups.com
                                    [mailto:extremeprogramming@yahoogroups.com] On Behalf Of zdnfa
                                    Sent: Friday, October 30, 2009 3:44 AM
                                    To: extremeprogramming@yahoogroups.com
                                    Subject: [XP] Re: XP is a philosophy not a religion






                                    --- In extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                    yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                    >
                                    > I get your point, and everything you said is true. However, XP doesn't
                                    > have any of these problems, because XP has the courage to say that the
                                    > team should be small, should sit together, and should function as a
                                    > working whole.
                                    >
                                    > What XP says to do isn't feasible for every project, every team, or
                                    > every organization. However, it does not follow that XP should
                                    > recommend something else in order to become a one size fits all
                                    > solution. Further, none of the changes you are recommending are novel.
                                    > They simply aren't part of XP by design.

                                    OK let try this:

                                    1. The lifecycle we are suggesting is this: analysis( one phase per
                                    release)plan for the releasequick
                                    designcodingrelease. Not every project requires an analysis
                                    phase, hence start by evaluating the project environment and see if it is
                                    well structured and you don't need this phase or otherwise. This is just a
                                    minor change to XP lifecycle.
                                    2. If you need this analysis phase then make your team as team of teams and
                                    let every pair do the analysis and we call this pair development rather than
                                    pair programming.
                                    3. In large projects, where you need to communicate with the customer in a
                                    formal manner, use models that are understandable for naïve customers such
                                    as swim lane diagram. (we had to develop a tax system for a country that is
                                    passing through drastic reform and this model was superior)
                                    4. Keep coding standards and have no mercy in this regard. Use continuous
                                    integration and have no mercy in this regard too. Use automated tests, and
                                    have no mercy here too. Use on-site-customer in the team structure: if she
                                    will not answer all your questions she'll be able to form the questions in a
                                    better way. Etc.
                                    So we still call ourselves XP'ers, and we want to remain so and for every
                                    project.

                                    Regards
                                    zaidoun






                                    [Non-text portions of this message have been removed]
                                  • zdnfa
                                    . ... short feedback through working software is imperative, this increases quality of software, we are by no means saying that analysis phase substitutes
                                    Message 17 of 24 , Oct 30, 2009
                                      .
                                      >
                                      > Substituting formal documentation for the short feedback loops and low

                                      short feedback through working software is imperative, this increases quality of software, we are by no means saying that analysis phase substitutes on-site-customer it just complements it in large projects

                                      regards
                                    • zdnfa
                                      ... I do agree with you that tacit knowledge is the decisive one, but when it comes to explicit knowledge i don t, why do we use coding standards? this is our
                                      Message 18 of 24 , Oct 30, 2009
                                        > Tacit knowledge is actually the only knowledge that leads to correct
                                        > action. Objective knowledge, if such a thing exists at all, is
                                        > passive and dead. Our job is to get the right tacit knowledge into
                                        > the heads of those who need it. Written material is one way to do
                                        > this, but not a very good one.

                                        I do agree with you that tacit knowledge is the decisive one, but when it comes to explicit knowledge i don't,

                                        why do we use coding standards? this is our main explicit form of this type of knowledge and it is not dead. In fact we always need it for the future start, where our tacit knowledge may not necessarily availabel!!
                                      • Adam Sroka
                                        ... Code is a form of explicit knowledge that matters. We need to code explicitly because machines don t have opinions nor do they appreciate nuance. I m not
                                        Message 19 of 24 , Oct 30, 2009
                                          On Fri, Oct 30, 2009 at 8:49 PM, zdnfa <zdnfa@...> wrote:
                                          >
                                          >
                                          >
                                          > > Tacit knowledge is actually the only knowledge that leads to correct
                                          > > action. Objective knowledge, if such a thing exists at all, is
                                          > > passive and dead. Our job is to get the right tacit knowledge into
                                          > > the heads of those who need it. Written material is one way to do
                                          > > this, but not a very good one.
                                          >
                                          > I do agree with you that tacit knowledge is the decisive one, but when it comes to explicit knowledge i don't,
                                          >
                                          > why do we use coding standards? this is our main explicit form of this type of knowledge and it is not dead. In fact we always need it for the future start, where our tacit knowledge may not necessarily availabel!!
                                          >

                                          Code is a form of explicit knowledge that matters. We need to code
                                          explicitly because machines don't have opinions nor do they appreciate
                                          nuance.

                                          I'm not sure what code standards have to do with that. Code standards
                                          per se are not knowledge at all, they are just about making code
                                          comprehensible to us non-machines.

                                          We spend a lot of time changing code. In fact, in Agile we spend more
                                          time changing code than almost anything else. We have to change it
                                          because it is wrong. Then when we make it right it becomes wrong
                                          again. It becomes wrong because it is explicit and real knowledge
                                          isn't.

                                          Understanding how and why the explicit knowledge in code becomes wrong
                                          is hard. That is why we need lots of tests. Tests break when we try to
                                          change things. That lets us know what we need to do to help the code
                                          to evolve towards what tacit truth is telling us. We can also add more
                                          tests when we learn new things about the stuff we thought we already
                                          knew.

                                          Documents are just as wrong as code. Documents don't break when we
                                          make them lie. Documents don't let us know how they need to change or
                                          when we get it right. Documents are hard to verify and thus harder to
                                          change.
                                        • zdnfa
                                          ... You are right, But as you just said, we need a self-documenting code in order to comprehend what has been done. This is exactly an explicit knowledge. The
                                          Message 20 of 24 , Oct 31, 2009
                                            >
                                            > Code is a form of explicit knowledge that matters. We need to code
                                            > explicitly because machines don't have opinions nor do they appreciate
                                            > nuance.
                                            >
                                            > I'm not sure what code standards have to do with that. Code standards
                                            > per se are not knowledge at all, they are just about making code
                                            > comprehensible to us non-machines.
                                            >
                                            > We spend a lot of time changing code. In fact, in Agile we spend more
                                            > time changing code than almost anything else. We have to change it
                                            > because it is wrong. Then when we make it right it becomes wrong
                                            > again. It becomes wrong because it is explicit and real knowledge
                                            > isn't.
                                            >
                                            > Understanding how and why the explicit knowledge in code becomes wrong
                                            > is hard. That is why we need lots of tests. Tests break when we try to
                                            > change things. That lets us know what we need to do to help the code
                                            > to evolve towards what tacit truth is telling us. We can also add more
                                            > tests when we learn new things about the stuff we thought we already
                                            > knew.
                                            >
                                            > Documents are just as wrong as code. Documents don't break when we
                                            > make them lie. Documents don't let us know how they need to change or
                                            > when we get it right. Documents are hard to verify and thus harder to
                                            > change.
                                            >


                                            You are right, But as you just said, we need a self-documenting code in order to comprehend what has been done. This is exactly an explicit knowledge. The question is: is that enough? can code reveal all what we need to know? We all know that a picture is worth 1000 words, don't you think that a reverse engineered code (one that has passed acceptance test) to a class diagram, use case, or swim lane diagram is easier to understand than reading a 1000 lines of code.

                                            Moreover, if we rely only on tacit knowledge, what happens if the expert programmer- the one who left his knowledge in term of code only- just leaves the organization?

                                            What you are saying right now is code and only code, what i'm saying is code is the most important artifact but models are laso helpful.

                                            regards
                                          • Ron Jeffries
                                            Hello, zdnfa. On Saturday, October 31, 2009, at 5:13:48 AM, you ... Code and tests may well be able to reveal everything we need to know. Code and tests and
                                            Message 21 of 24 , Oct 31, 2009
                                              Hello, zdnfa. On Saturday, October 31, 2009, at 5:13:48 AM, you
                                              wrote:

                                              > You are right, But as you just said, we need a self-documenting
                                              > code in order to comprehend what has been done. This is exactly an
                                              > explicit knowledge. The question is: is that enough? can code
                                              > reveal all what we need to know?

                                              Code and tests may well be able to reveal everything we need to
                                              know. Code and tests and conversation certainly can. Sometimes that
                                              conversation will take place in front of a whiteboard, or with some
                                              CRC cards on the table.

                                              > We all know that a picture is
                                              > worth 1000 words, don't you think that a reverse engineered code
                                              > (one that has passed acceptance test) to a class diagram, use
                                              > case, or swim lane diagram is easier to understand ... [than
                                              > reading 1000 lines of code].

                                              Of course diagrams are important: people here have mentioned that
                                              many times in this very thread.

                                              What is /not/ important, in our opinion, is to make any particular
                                              diagram an official part of XP. Communication is one of the XP
                                              values. We give examples of many ways of communicating. We do not
                                              have particular written forms which are blessed as necessary. This
                                              is the case for a number of reasons, including:

                                              Many individuals and teams lean on written forms of communication
                                              when conversational forms would be better. Some of us refuse to
                                              make any written form of communication "official" to emphasize
                                              that all of them are inferior to conversation.

                                              When a picture or diagram is most valuable is in conversation. And
                                              few, if any, pictures actually stand alone. Generally any software
                                              diagram comes with many paragraphs of text explaining what it
                                              means. So wise developers draw their diagrams in the moment, as
                                              they explain in words what is being described.

                                              > [easier to understand] than reading 1000 lines of code.

                                              Easier, or less complete? To understand 1000 lines of code, we must
                                              read the code, and probably need to read a lot of code that uses the
                                              1000 lines in question.

                                              To get an //overview// of the code, sometimes a diagram will help
                                              us. This is easier, only in that it is less complete. If we want
                                              incomplete knowledge of the code, for some reason, a diagram may
                                              still not be the best way to get it.

                                              > Moreover, if we rely only on tacit knowledge, what happens if the
                                              > expert programmer- the one who left his knowledge in term of code
                                              > only- just leaves the organization?

                                              With respect, I believe that by asking this question you show some
                                              kind of misunderstanding of a key XP value: Communication. XP is a
                                              team discipline. Through pair programming and team code ownership,
                                              XP teams avoid having knowledge reside in just one person. In an XP
                                              team, practicing pairing and team code ownership, the whole team
                                              knows, and improves, the code.

                                              (You are probably now tempted to ask "OK, but what if the whole
                                              team leaves the organization or is reassigned." To do so would be
                                              to miss the more essential point, which is that when you are doing
                                              XP, you have the tacit knowledge--the only kind that works--spread
                                              throughout the whole team. It is very difficult to lose tacit
                                              knowledge in that situation.)

                                              I want to underline an earlier point: "Knowledge" written down, what
                                              you are calling in this thread "explicit knowledge", is not
                                              knowledge at all. It is information. Knowledge, what you call "tacit
                                              knowledge", is what matters: the contents of our heads. XP's
                                              communication value is about having a shared understanding. Wise
                                              players and teams use many means to make that happen. XP does not
                                              dictate many of those means, and that is intentional.

                                              > What you are saying right now is code and only code, what i'm
                                              > saying is code is the most important artifact but models are laso
                                              > helpful.

                                              I haven't heard anyone say "code and only code" ... what is
                                              important to remember, though, is that only the code is guaranteed
                                              to tell the truth, and as such it is primary with respect to
                                              explaining what the system really is.

                                              All the teams I know use diagrams and pictures and other means. XP
                                              does not prescribe what those are, and in my strong opinion it
                                              should not.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              www.xprogramming.com/blog
                                              It's easier to act your way into a new way of thinking
                                              than to think your way into a new way of acting. --Millard Fuller
                                            • Steven Gordon
                                              ... Of course! Automated reverse engineering of the code can be done whenever anybody needs that particular view of the software. It does not need to be
                                              Message 22 of 24 , Oct 31, 2009
                                                On Sat, Oct 31, 2009 at 2:13 AM, zdnfa <zdnfa@...> wrote:
                                                >

                                                >
                                                > You are right, But as you just said, we need a self-documenting code in order to comprehend what has been done. This is exactly an explicit knowledge.
                                                > The question is: is that enough? can code reveal all what we need to know? We all know that a picture is worth 1000 words, don't you think that a reverse
                                                > engineered code (one that has passed acceptance test) to a class diagram, use case, or swim lane diagram is easier to understand than reading a 1000
                                                > lines of code.

                                                Of course! Automated reverse engineering of the code can be done
                                                whenever anybody needs that particular view of the software. It does
                                                not need to be saved as a permanent document, nor does the process
                                                have to prescribe always producing it or using it. Under XP, we trust
                                                the developers to be responsible enough to use the tools appropriate
                                                to what they are working on. Sometimes reverse-engineered UML would
                                                be appropriate, sometimes it would be a total waste of time. If we
                                                have to prescribe this, we have 'programmers' not developers.

                                                >
                                                > Moreover, if we rely only on tacit knowledge, what happens if the expert programmer- the one who left his knowledge in term of code only- just leaves the organization?

                                                I have been in this position many times. I have found that the design
                                                documentation left behind a project is never more than 80% accurate,
                                                usually much less. Filtering truth from fiction is so much wasted
                                                work compared to proceeding with readable, well-organized code and
                                                working, readable automated tests. Automated reverse-engineered UML
                                                diagram are very useful if the programming language supports it.

                                                I have found user documentation much more helpful than design
                                                documentation, because generally it accurately reflects what the
                                                system actually does (more than requirements documentation do).

                                                >
                                                > What you are saying right now is code and only code, what i'm saying is code is the most important artifact but models are laso helpful.

                                                Code and automated unit tests are the minimum. Often they are
                                                sufficient. It is up to the team to decide what additional artefacts
                                                are worthwhile for what they are doing at each specific point in time
                                                in their specific context.

                                                >
                                                > regards
                                                >
                                              • Adam Sroka
                                                ... It depends on how well written the code is. If the code is well written I won t have to read all 1,000 lines to find what I need to know. Possibly not even
                                                Message 23 of 24 , Oct 31, 2009
                                                  On Sat, Oct 31, 2009 at 2:13 AM, zdnfa <zdnfa@...> wrote:
                                                  >
                                                  >
                                                  >
                                                  > >
                                                  > > Code is a form of explicit knowledge that matters. We need to code
                                                  > > explicitly because machines don't have opinions nor do they appreciate
                                                  > > nuance.
                                                  > >
                                                  > > I'm not sure what code standards have to do with that. Code standards
                                                  > > per se are not knowledge at all, they are just about making code
                                                  > > comprehensible to us non-machines.
                                                  > >
                                                  > > We spend a lot of time changing code. In fact, in Agile we spend more
                                                  > > time changing code than almost anything else. We have to change it
                                                  > > because it is wrong. Then when we make it right it becomes wrong
                                                  > > again. It becomes wrong because it is explicit and real knowledge
                                                  > > isn't.
                                                  > >
                                                  > > Understanding how and why the explicit knowledge in code becomes wrong
                                                  > > is hard. That is why we need lots of tests. Tests break when we try to
                                                  > > change things. That lets us know what we need to do to help the code
                                                  > > to evolve towards what tacit truth is telling us. We can also add more
                                                  > > tests when we learn new things about the stuff we thought we already
                                                  > > knew.
                                                  > >
                                                  > > Documents are just as wrong as code. Documents don't break when we
                                                  > > make them lie. Documents don't let us know how they need to change or
                                                  > > when we get it right. Documents are hard to verify and thus harder to
                                                  > > change.
                                                  > >
                                                  >
                                                  > You are right, But as you just said, we need a self-documenting code in order to comprehend what has been done. This is exactly an explicit knowledge. The question is: is that enough? can code reveal all what we need to know? We all know that a picture is worth 1000 words, don't you think that a reverse engineered code (one that has passed acceptance test) to a class diagram, use case, or swim lane diagram is easier to understand than reading a 1000 lines of code.
                                                  >

                                                  It depends on how well written the code is. If the code is well
                                                  written I won't have to read all 1,000 lines to find what I need to
                                                  know. Possibly not even 100. As a programmer, if the UML diagram is
                                                  easier for me to understand than my code then I have a lot of work to
                                                  do.

                                                  > Moreover, if we rely only on tacit knowledge, what happens if the expert programmer- the one who left his knowledge in term of code only- just leaves the organization?
                                                  >

                                                  I don't really know the answer to that, but from experience I can tell
                                                  you that we aren't much better off if he leaves behind a document.

                                                  > What you are saying right now is code and only code, what i'm saying is code is the most important artifact but models are laso helpful.
                                                  >

                                                  Actually, that's an interesting interpretation of what I said. What I
                                                  meant was code is the only form of explicit knowledge that is
                                                  necessary in software projects (Necessary because of the nature of
                                                  machines.) And, that because code is necessarily explicit we must work
                                                  hard to control it and manage change.

                                                  I did not say that code is the only thing that matters. Conversation
                                                  and collaboration matter. Business value, quality, and usability
                                                  matter. None of these things are explicit enough to be captured in
                                                  documents.
                                                • Tim Ottinger
                                                  I applaud all attempts to take good software development in any and all new directions, provided that the experimenter is not merely trying to adapt the name
                                                  Message 24 of 24 , Nov 10, 2009
                                                    I applaud all attempts to take good software development in any and all new directions, provided that the experimenter is not merely trying to adapt the name "agile" to their old process. It is far better to "be" than to "seem."

                                                    Try whatever you like, don't let barking dogs distract you, and do be conscientious in your application. Measure, report, etc.

                                                    I have found remote pairing to be very successful, despite the personal belief that it would not work, and could not be made to work. It is not perfect, and is second-best in many ways to being physically present, but has advantages and trade-offs.

                                                    In the same way, try new things (and old things) in your agile adventure. Remember that the goal is learning, and finding ways to learn better. Avoid learning-suppression systems and keep moving.

                                                    As regards docs:

                                                    Mockups are good. After all, "it's always a good time to build an
                                                    example", but once the example is implemented in code or tests, it is
                                                    available to all and the original model is not useful. I believe in creating small docs, but only to later obviate and then delete them.

                                                    Tim Ottinger
                                                    http://agileinaflash.blogspot.com/
                                                    http://agileotter.blogspot.com/
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.