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

Re: [XP] Re: XP is a philosophy not a religion

Expand Messages
  • 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 1 of 24 , Oct 29, 2009
    • 0 Attachment
      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 2 of 24 , Oct 29, 2009
      • 0 Attachment
        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 3 of 24 , Oct 30, 2009
        • 0 Attachment
          --- 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 4 of 24 , Oct 30, 2009
          • 0 Attachment
            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 5 of 24 , Oct 30, 2009
            • 0 Attachment
              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 6 of 24 , Oct 30, 2009
              • 0 Attachment
                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 7 of 24 , Oct 30, 2009
                • 0 Attachment
                  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 8 of 24 , Oct 30, 2009
                  • 0 Attachment
                    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 9 of 24 , Oct 30, 2009
                    • 0 Attachment
                      .
                      >
                      > 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 10 of 24 , Oct 30, 2009
                      • 0 Attachment
                        > 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 11 of 24 , Oct 30, 2009
                        • 0 Attachment
                          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 12 of 24 , Oct 31, 2009
                          • 0 Attachment
                            >
                            > 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 13 of 24 , Oct 31, 2009
                            • 0 Attachment
                              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 14 of 24 , Oct 31, 2009
                              • 0 Attachment
                                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 15 of 24 , Oct 31, 2009
                                • 0 Attachment
                                  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 16 of 24 , Nov 10, 2009
                                  • 0 Attachment
                                    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.