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

XP as a hackarama

Expand Messages
  • wecaputo@thoughtworks.com
    To the tactful and compelling in the group: Ideas for dealing with the objection that XP results in hacked up design. What I am seeing is that a big objection
    Message 1 of 27 , Sep 27, 2000
    • 0 Attachment
      To the tactful and compelling in the group:

      Ideas for dealing with the objection that XP results in hacked up design.

      What I am seeing is that a big objection -- or at least skeptisim -- from
      developers who are used to more "traditonal" methods of software
      development is that they see the lack of extensive architectural detail,
      and design sessions as leading to a hack job.

      What I am looking for is some compelling ways to meet (and hopefully
      overcome) these sorts of objections.

      I feel that the answer lies in the fact that big "perfect" architectures
      explore all kinds of possibilities -- on paper -- but don't in fact deal
      with any reality. XP overcomes this by evolving the architecture through
      such practices as Once and Only Once, and Do the Simplest Thing That Can
      Possibly Work, and MercilessRefactoring.

      What I want is an argument - not an XP lexicon. Those acronyms won't have
      any meaning to non-XP'rs, and so I think an argument without them is a
      better answer.

      BTW, I am a lousy salesman :)

      Thanks,
      Bill
    • C & C Helck
      I have limited experience here, but it seems that under XP you do design differently. In a previous project I was a lead programmer and involved in the BUFD.
      Message 2 of 27 , Sep 27, 2000
      • 0 Attachment
        I have limited experience here, but it seems that under XP you do design
        differently. In a previous project I was a lead programmer and involved in
        the BUFD. For the most part the designers worked by themselves creating UML
        diagrams with Rose. We interacted as necessary (an hour a day) and had
        semi-formal reviews and inspections. So basically I knew my design and Joe
        new his. When I reviewed Joe's work I concentrated on the interfaces more
        than his internal design. When the designs are presented to the rest of the
        staff I've noticed a lot of confusion and glazed eyeballs. It takes a long
        time for the programmers to come up to speed on the design.

        With my XP-ish team of seven we have a lot more discussions about design.
        Most of our meetings are unplanned and can involve a few members or the
        whole group. Everyone in the group understands the design. It seems like
        misunderstandings are discovered pretty quickly, discussed by at least two
        people, and are often resolved on the spot. In XP I think the designs are
        thought about, talked about, used, and played with more (and by more
        people) than more traditional methods. Basically theres just a ton of
        feedback early on.

        The main objection I get about XP's design process is its lack of
        documentation. To say "The code is the design" scares the hell out of most
        people. They want a document that is not as detailed as code, but is
        detailed and complete enough so that they can independently verify the
        design before they pay for the development effort. We record our designs on
        white boards that get erased frequently. It seems to work, but its tough to
        convince others.

        Good luck,
        C. Helck

        At 05:32 PM 9/27/00 -0500, you wrote:
        >To the tactful and compelling in the group:
        >
        >Ideas for dealing with the objection that XP results in hacked up design.
        >
        >What I am seeing is that a big objection -- or at least skeptisim -- from
        >developers who are used to more "traditonal" methods of software
        >development is that they see the lack of extensive architectural detail,
        >and design sessions as leading to a hack job.
        >
        >What I am looking for is some compelling ways to meet (and hopefully
        >overcome) these sorts of objections.
        >
        >I feel that the answer lies in the fact that big "perfect" architectures
        >explore all kinds of possibilities -- on paper -- but don't in fact deal
        >with any reality. XP overcomes this by evolving the architecture through
        >such practices as Once and Only Once, and Do the Simplest Thing That Can
        >Possibly Work, and MercilessRefactoring.
        >
        >What I want is an argument - not an XP lexicon. Those acronyms won't have
        >any meaning to non-XP'rs, and so I think an argument without them is a
        >better answer.
        >
        >BTW, I am a lousy salesman :)
        >
        >Thanks,
        >Bill
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to:
        >extremeprogramming-unsubscribe@...
        >
        >Ad-free courtesy of objectmentor.com
      • Johannes Brodwall
        There was a discussion on this mailing list some time ago regarding the Driving Metaphor which I found to be very enlightening. I think the original thread
        Message 3 of 27 , Sep 28, 2000
        • 0 Attachment
          There was a discussion on this mailing list some time ago regarding the
          Driving Metaphor which I found to be very enlightening. I think the
          original thread was called "XP and my boss". See especially uncle Bob's
          mail 10973.

          To sum up the argument, one of the perceived problems with XP's lack of BDUF
          is that "adjusting as you drive" works well until you finally run into grand
          canyon. Then you will have a lot of backtracking to do. Some of the
          discussion indicated that this hardly ever happens. More importantly,
          however, is the fact that there is no or little evidence for up-front
          designs addressing this any better than continous design. The idea is to
          get a map of the terrain, but the map is mostly so incorrect and/or
          imprecise that it is of no help.

          Some more ammunition:

          - "How can I know what design issues arise before I have written the code?"
          See the discussion about "Extreme Writing", where Kent [msg: 11138] says
          that since the "design" when writing a book will be unusable any way, so
          skipping it might be just as well.

          - The whole discussion about "adaptive vs predictive" thinking. With a
          project of any size, you cannot predict all the problems you run into, so it
          might be wiser to make sure that you can adapt instead.

          In conclusion: If XP leads to hacked up design, it is no different from any
          BDUF methodology, just a bit quicker. Since it has a simple design,
          however, it should easier to change. The important thing is reflecting
          about what you should do before you do it. With it's testing-first
          philosophy, XP addresses this quite pragmatically.

          Sincely,
          Johannes Brodwall


          ----- Original Message -----
          From: <wecaputo@...>
          To: <extremeprogramming@egroups.com>
          Sent: Thursday, September 28, 2000 12:32 AM
          Subject: [XP] XP as a hackarama


          > To the tactful and compelling in the group:
          >
          > Ideas for dealing with the objection that XP results in hacked up design.
          >
          > What I am seeing is that a big objection -- or at least skeptisim -- from
          > developers who are used to more "traditonal" methods of software
          > development is that they see the lack of extensive architectural detail,
          > and design sessions as leading to a hack job.
          >
          > What I am looking for is some compelling ways to meet (and hopefully
          > overcome) these sorts of objections.
          >
          > I feel that the answer lies in the fact that big "perfect" architectures
          > explore all kinds of possibilities -- on paper -- but don't in fact deal
          > with any reality. XP overcomes this by evolving the architecture through
          > such practices as Once and Only Once, and Do the Simplest Thing That Can
          > Possibly Work, and MercilessRefactoring.
          >
          > What I want is an argument - not an XP lexicon. Those acronyms won't have
          > any meaning to non-XP'rs, and so I think an argument without them is a
          > better answer.
          >
          > BTW, I am a lousy salesman :)
          >
          > Thanks,
          > Bill
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...
          >
          > Ad-free courtesy of objectmentor.com
          >
        • Arrizza, John
          ... Known to be neither but... ... of ... Their position comes from egotism and fear. They fear that they will make a mistake in the architecture and won t be
          Message 4 of 27 , Sep 28, 2000
          • 0 Attachment
            > -----Original Message-----
            > From: wecaputo@... [mailto:wecaputo@...]
            > To the tactful and compelling in the group:
            Known to be neither but...

            > What I am seeing is that a big objection -- or at least
            > skepticism -- from developers who are used to more "traditional" methods
            of
            > software development is that they see the lack of extensive
            > architectural detail, and design sessions as leading to a hack job.
            Their position comes from egotism and fear. They fear that they will make a
            mistake in the architecture and won't be able to fix it later unless they
            analyze everything up front. Egotism because they think that they *can*
            analyze everything up front. So whatever tack you take it must appease their
            egotism and fear.

            > I feel that the answer lies in the fact that big "perfect"
            > architectures explore all kinds of possibilities -- on paper -- but don't
            > in fact deal with any reality. XP overcomes this by evolving the
            > architecture through such practices as Once and Only Once, and Do the
            > Simplest Thing That Can Possibly Work, and MercilessRefactoring.
            I'd say give in and agree that a "perfect" architecture and up front design
            are needed. BUT you want to test their ideas by prototyping the architecture
            in code. This way they don't have to give up their ideas and you get them
            coding up front. Claim you're a realist and that you just want to test the
            design in the "harsh light of reality" or "the school of hard knocks" or
            some other '40s movie cliche. They'll probably jump at this because they'll
            see it as a way to reduce their anxieties about their design.

            Say that the prototype should be fairly accurate to the architecture that
            they want to implement. Your reasoning will be that small differences in the
            architecture can have big effects on overall efficacy and usability of that
            design. This way the code from the existing prototype can be just extended
            later on. They'll probably jump at this as well because it appeals to
            perfectionist and analyst mentalities.

            Don't let them do BUFD just a SmallUFD, a bit of code, SmallUFD, a bit of
            code. But hey, look at that, you have a working prototype! So test it using
            some UTs and FTs. That way they get used to design, code, test, etc all the
            while extending the "prototype" to usable code. If you're lucky good things
            will happen: first they'll get comfortable with the quick design/code cycle.
            Then they'll get lazy (in the best possible sense of that word) and drop the
            size of the SmallUFD to XP levels. They may not however.

            If they are amenable to PairProgramming, do the prototype in pairs
            especially if you can get the current Champion to help out. That way you can
            point out the flaws, if any, in their architecture and you can fix the flaws
            right then and there. If there aren't any flaws... great!

            If you can, on the side, RefactorMercilessly and add UTs everywhere. Feed
            back the things you learn doing this to the design team. They'll think your
            prescient and omniscient.

            When they are "ready to start coding", point proudly to the prototype and
            then use it as a base to finish the product using XP techniques (assuming
            they are amenable to TestFirst and RefactorMercilessly).

            my 2 baht.
            John
          • wecaputo@thoughtworks.com
            Thank you Johannes, this is the kind of stuff I wanted -- sound bites :) I remember that Grand Canyon thread now that you mention it. It was a good one, thanks
            Message 5 of 27 , Sep 28, 2000
            • 0 Attachment
              Thank you Johannes, this is the kind of stuff I wanted -- sound bites :)

              I remember that Grand Canyon thread now that you mention it. It was a good
              one, thanks for reminding me, I think I will go re-read it.

              Best,
              Bill




              "Johannes
              Brodwall" To: <extremeprogramming@egroups.com>
              <johannes@bro cc:
              dwall.com> Subject: Re: [XP] XP as a hackarama

              09/28/2000
              06:25 AM
              Please
              respond to
              extremeprogra
              mming





              There was a discussion on this mailing list some time ago regarding the
              Driving Metaphor which I found to be very enlightening. I think the
              original thread was called "XP and my boss". See especially uncle Bob's
              mail 10973.

              To sum up the argument, one of the perceived problems with XP's lack of
              BDUF
              is that "adjusting as you drive" works well until you finally run into
              grand
              canyon. Then you will have a lot of backtracking to do. Some of the
              discussion indicated that this hardly ever happens. More importantly,
              however, is the fact that there is no or little evidence for up-front
              designs addressing this any better than continous design. The idea is to
              get a map of the terrain, but the map is mostly so incorrect and/or
              imprecise that it is of no help.

              Some more ammunition:

              - "How can I know what design issues arise before I have written the code?"
              See the discussion about "Extreme Writing", where Kent [msg: 11138] says
              that since the "design" when writing a book will be unusable any way, so
              skipping it might be just as well.

              - The whole discussion about "adaptive vs predictive" thinking. With a
              project of any size, you cannot predict all the problems you run into, so
              it
              might be wiser to make sure that you can adapt instead.

              In conclusion: If XP leads to hacked up design, it is no different from
              any
              BDUF methodology, just a bit quicker. Since it has a simple design,
              however, it should easier to change. The important thing is reflecting
              about what you should do before you do it. With it's testing-first
              philosophy, XP addresses this quite pragmatically.

              Sincely,
              Johannes Brodwall


              ----- Original Message -----
              From: <wecaputo@...>
              To: <extremeprogramming@egroups.com>
              Sent: Thursday, September 28, 2000 12:32 AM
              Subject: [XP] XP as a hackarama


              > To the tactful and compelling in the group:
              >
              > Ideas for dealing with the objection that XP results in hacked up design.
              >
              > What I am seeing is that a big objection -- or at least skeptisim -- from
              > developers who are used to more "traditonal" methods of software
              > development is that they see the lack of extensive architectural detail,
              > and design sessions as leading to a hack job.
              >
              > What I am looking for is some compelling ways to meet (and hopefully
              > overcome) these sorts of objections.
              >
              > I feel that the answer lies in the fact that big "perfect" architectures
              > explore all kinds of possibilities -- on paper -- but don't in fact deal
              > with any reality. XP overcomes this by evolving the architecture through
              > such practices as Once and Only Once, and Do the Simplest Thing That Can
              > Possibly Work, and MercilessRefactoring.
              >
              > What I want is an argument - not an XP lexicon. Those acronyms won't have
              > any meaning to non-XP'rs, and so I think an argument without them is a
              > better answer.
              >
              > BTW, I am a lousy salesman :)
              >
              > Thanks,
              > Bill
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...
              >
              > Ad-free courtesy of objectmentor.com
              >


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

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

              Ad-free courtesy of objectmentor.com
            • Bruce Winegarden
              XP results in hacked up design - Yes it can happen to you. This is a real problem and needs to be a daily concern for an XP team. Our XP project experience
              Message 6 of 27 , Sep 28, 2000
              • 0 Attachment
                "XP results in hacked up design" - Yes it can happen to you.
                This is a real problem and needs to be a daily concern for an XP team.
                Our XP project experience and feedback from talking to other people on XP
                teams is that it takes extra discipline to stop coding and recognize when
                you need to work out a better design.

                I am more interested in hearing about what other XP teams have done to
                arrive at good designs than arguments to skeptics about why they shouldn't
                criticize XP.

                We just had an afternoon design discussion about what we learned from our 8
                week Release 1 experience. We have had some great revelations in emergent
                design that resulting in what we think is good design. We also have some
                hacked up code that is in serious need of re-design and re-factoring. A
                lesson learned for our team was that we would have been better off if we had
                done more design earlier. I'm not talking about BDUF (Big Design Up Front).

                One example:
                We talked about symptoms to recognize when design should be broader than an
                active pair. Some ideas:
                1) When your current task has you roaming over and making changes to many
                classes across the entire system.
                2) When you indentify a desired refactoring that is much larger than the
                duration of a task or pair coding episode.
                3) Behavour you are having trouble figuring out how to unit test.

                I think we spend too much time thinking about what the non-using critics of
                XP think or say about it. We need to spend more time being honest about
                real issues with the XP process. This has been a real problem for XP team
                and most other teams I have talked with.

                Maybe this is a new thread. Please respond with real experiences that have
                worked to improve design discipline in other XP projects.

                Bruce Winegarden
                Product Sight
                (425) 467-7117


                -----Original Message-----
                From: wecaputo@... [mailto:wecaputo@...]
                Sent: Wednesday, September 27, 2000 3:32 PM
                To: extremeprogramming@egroups.com
                Subject: [XP] XP as a hackarama


                To the tactful and compelling in the group:

                Ideas for dealing with the objection that XP results in hacked up design.

                What I am seeing is that a big objection -- or at least skeptisim -- from
                developers who are used to more "traditonal" methods of software
                development is that they see the lack of extensive architectural detail,
                and design sessions as leading to a hack job.

                What I am looking for is some compelling ways to meet (and hopefully
                overcome) these sorts of objections.

                I feel that the answer lies in the fact that big "perfect" architectures
                explore all kinds of possibilities -- on paper -- but don't in fact deal
                with any reality. XP overcomes this by evolving the architecture through
                such practices as Once and Only Once, and Do the Simplest Thing That Can
                Possibly Work, and MercilessRefactoring.

                What I want is an argument - not an XP lexicon. Those acronyms won't have
                any meaning to non-XP'rs, and so I think an argument without them is a
                better answer.

                BTW, I am a lousy salesman :)

                Thanks,
                Bill


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

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

                Ad-free courtesy of objectmentor.com
              • Ian Rae
                ... Try discussing how requirements ALWAYS change and that a lot of up-front analysis and design may not be that valuable in the end. Kent Beck s article in
                Message 7 of 27 , Sep 28, 2000
                • 0 Attachment
                  > From: wecaputo@...

                  >To the tactful and compelling in the group:
                  >
                  >Ideas for dealing with the objection that XP results in hacked up design.
                  >[..]

                  Try discussing how requirements ALWAYS change and that a lot of up-front analysis and
                  design may not be that valuable in the end.

                  Kent Beck's article in the Files section
                  Optional scope contracts.pdf </files/extremeprogramming/Optional+scope+contracts.pdf>
                  begins with this quote:

                  "Customers can now have what they want at the project end, after all they've learned, instead
                  of getting what they wanted at the project start."

                  --Ian
                • Ron Jeffries
                  ... It seems to me that we always need a better design. The question is how to get it. There are a couple of places where the whole team can get involved in
                  Message 8 of 27 , Sep 28, 2000
                  • 0 Attachment
                    At 07:56 AM 9/28/00 -0700, Bruce Winegarden wrote:
                    >"XP results in hacked up design" - Yes it can happen to you.
                    >This is a real problem and needs to be a daily concern for an XP team.
                    >Our XP project experience and feedback from talking to other people on XP
                    >teams is that it takes extra discipline to stop coding and recognize when
                    >you need to work out a better design.

                    It seems to me that we always need a better design. The question is how to
                    get it. There are a couple of places where the whole team can get involved
                    in design in "standard" XP.

                    First, during iteration planning, the Team Brainstorms Tasks. This is
                    design, and if you skip it, you are skipping a chance for the whole team to
                    learn a bit about the whole design, and for the design to evolve in the
                    presence of everyone.

                    Second, Quick Design Session. Before starting some new thing, the pair who
                    are going to work on it realize that they could use a little design boost.
                    They get a few people together - up to the entire team - and spend a little
                    time doing a design sketch. CRC around the table works incredibly well for
                    this. UML on the whiteboard works fairly well. This process lets everyone
                    learn about and contribute to the design, in a more focused way than in the
                    iteration planning process.

                    Quick Design Session means quick. A half hour, in my opinion, is the
                    maximum. Try for ten minutes, then invoke the Ten Minute Rule: Whenever
                    more than two programmers discuss a design issue for more than ten minutes,
                    the issue must be resolved by an experiment in code.

                    >We just had an afternoon design discussion about what we learned from our 8
                    >week Release 1 experience. We have had some great revelations in emergent
                    >design that resulting in what we think is good design. We also have some
                    >hacked up code that is in serious need of re-design and re-factoring. A
                    >lesson learned for our team was that we would have been better off if we had
                    >done more design earlier.

                    Let me respectfully suggest that this isn't the only possible
                    interpretation of the data.

                    It is possible that more and earlier design would have resulted in better
                    code - with any luck at all, it would. It would also take some time and
                    would almost certainly produce design ideas or code that would be unused in
                    the system today (but which might be useful later). If the earlier design
                    you are talking about was on the order of a half-hour - see Quick Design
                    Session - then I'm with you.

                    However, the team observed "hacked-up code that is in serious need of
                    re-design and re-factoring". I'll wager that when you had the meeting,
                    people already knew that the code was - in your terms - hacked-up.

                    Another approach, instead of doing design up front speculatively - hoping
                    that it will reduce hacked-up code - what would happen if people who
                    recognize that they are creating hacked-up code would stop and clean it
                    then and there? What would happen if when we encounter bad code, we would
                    clean it then and there? What would happen if when we feel ourselves
                    writing ugly code, we stop and call a third part or a Quick Design Session.

                    Finally, you don't mention whether your team is practicing pair
                    programming. Is there any correlation between the poor code and
                    single-programmer work? Was the bulk of it produced by someone or someones
                    who need a little more help?

                    Don't get me wrong. I like a little bit of up front design. It keeps the
                    team on the same page, and helps people keep from going in the wrong
                    direction. But what you describe - hacked-up code needing redesign and
                    refactoring - doesn't sound like a design problem to me as much as it
                    sounds like a coding problem.

                    I could be wRONg, of course. ;->

                    R

                    Ronald E Jeffries
                    http://www.XProgramming.com
                    http://www.objectmentor.com
                  • Joshua Kerievsky
                    ... Bruce - did you do one 8-week iteration or was the 8-week release composed of smaller iterations? I ask, because I find that 3-week iterations give us a
                    Message 9 of 27 , Sep 28, 2000
                    • 0 Attachment
                      >We just had an afternoon design discussion about what we learned from our 8
                      >week Release 1 experience. We have had some great revelations in emergent
                      >design that resulting in what we think is good design. We also have some
                      >hacked up code that is in serious need of re-design and re-factoring. A
                      >lesson learned for our team was that we would have been better off if we had
                      >done more design earlier. I'm not talking about BDUF (Big Design Up Front).

                      Bruce - did you do one 8-week iteration or was the 8-week release composed of
                      smaller iterations? I ask, because I find that 3-week iterations give us a
                      chance to catch our breath and reflect on what we've done.

                      >One example:
                      >We talked about symptoms to recognize when design should be broader than an
                      >active pair. Some ideas:
                      >1) When your current task has you roaming over and making changes to many
                      >classes across the entire system.
                      >2) When you indentify a desired refactoring that is much larger than the
                      >duration of a task or pair coding episode.

                      At Evant, we began by writing such "desired" refactorings down on index cards.
                      We kept the index cards in the middle of the table and watched the pile grow or
                      shrink. A few months later, the pile was growing too high. It becomes clear
                      that the desired refactorings needed to be managed and dispatched. The XP
                      coach now does this, with the help of our intranet. I still like writing on
                      cards because I can do it very fast as my pair continues to program -- but it
                      is good to eventually transfer the refactoring idea to an electronic form.

                      As for larger refactorings -- we've had this discussion before on this list.
                      It is best to not have 'em. If you can work hard to not have large
                      refactorings, great. But I find that you do encounter them. So a strategy is
                      needed.

                      For big refactorings, it is really up to Business to decide if they want to
                      invest in the work (Ron has mentioned this idea before). It is not at all
                      unreasonable to sell Business on the benefits of a large refactoring. We're
                      currently doing a large refactoring involving XSLT -- and it has a direct
                      impact on the agility of the software in the face of a growing customer base.
                      In other words, this refactoring makes business sense.

                      That said, we also do medium sized refactorings which business never knows
                      about.

                      For medium to large-refactorings, it is good to break off for quick 10-15
                      minute design meetings -- with say 4-5 programmers and the coach. We do this
                      quite often.

                      I also favor having XP teams know and continue to learn the "good" patterns
                      literature. That takes discipline. The knowledge learned from the patterns
                      literature is particulalry important for refactorings (large and small) and
                      design dialogues. If your team lacks knowledge of patterns, I'd suggest having
                      a weekly patterns study group perhaps combined with a lunch or dinner.

                      regards
                      jk
                    • Bruce Winegarden
                      Ron, I didn t say our lesson was desgin up front but more design earlier. Your suggestion on Quick Design Session is very useful. The rest of your comments
                      Message 10 of 27 , Sep 28, 2000
                      • 0 Attachment
                        Ron,
                        I didn't say our lesson was "desgin up front" but "more design earlier."
                        Your suggestion on Quick Design Session is very useful.

                        The rest of your comments appear to say if only we were doing XP "right" we
                        wouldn't have this problem. That is an attitude on this list that is not
                        helpful.

                        Our team has followed XP by the book as close as a new team could expect.
                        Yes we do design in Interation planning, All production code written by a
                        pair etc...

                        There remains a very common XP problem of how to handle large refactorings
                        that are the result of poor design decisions. Or shall I be XP politically
                        correct? Emergent design that turns out to be expensive and difficult to
                        extend. Politically incorrect = hacked up code.

                        Large refactorings cost customer velocity.
                        How can we avoid them as much as possible?
                        When we don't how should we fix them?


                        Bruce Winegarden
                        Product Sight
                        (425) 467-7117


                        -----Original Message-----
                        From: Ron Jeffries [mailto:ronjeffries@...]
                        Sent: Thursday, September 28, 2000 8:18 AM
                        To: extremeprogramming@egroups.com
                        Subject: RE: [XP] XP as a hackarama


                        At 07:56 AM 9/28/00 -0700, Bruce Winegarden wrote:
                        >"XP results in hacked up design" - Yes it can happen to you.
                        >This is a real problem and needs to be a daily concern for an XP team.
                        >Our XP project experience and feedback from talking to other people on XP
                        >teams is that it takes extra discipline to stop coding and recognize when
                        >you need to work out a better design.

                        It seems to me that we always need a better design. The question is how to
                        get it. There are a couple of places where the whole team can get involved
                        in design in "standard" XP.

                        First, during iteration planning, the Team Brainstorms Tasks. This is
                        design, and if you skip it, you are skipping a chance for the whole team to
                        learn a bit about the whole design, and for the design to evolve in the
                        presence of everyone.

                        Second, Quick Design Session. Before starting some new thing, the pair who
                        are going to work on it realize that they could use a little design boost.
                        They get a few people together - up to the entire team - and spend a little
                        time doing a design sketch. CRC around the table works incredibly well for
                        this. UML on the whiteboard works fairly well. This process lets everyone
                        learn about and contribute to the design, in a more focused way than in the
                        iteration planning process.

                        Quick Design Session means quick. A half hour, in my opinion, is the
                        maximum. Try for ten minutes, then invoke the Ten Minute Rule: Whenever
                        more than two programmers discuss a design issue for more than ten minutes,
                        the issue must be resolved by an experiment in code.

                        >We just had an afternoon design discussion about what we learned from our 8
                        >week Release 1 experience. We have had some great revelations in emergent
                        >design that resulting in what we think is good design. We also have some
                        >hacked up code that is in serious need of re-design and re-factoring. A
                        >lesson learned for our team was that we would have been better off if we
                        had
                        >done more design earlier.

                        Let me respectfully suggest that this isn't the only possible
                        interpretation of the data.

                        It is possible that more and earlier design would have resulted in better
                        code - with any luck at all, it would. It would also take some time and
                        would almost certainly produce design ideas or code that would be unused in
                        the system today (but which might be useful later). If the earlier design
                        you are talking about was on the order of a half-hour - see Quick Design
                        Session - then I'm with you.

                        However, the team observed "hacked-up code that is in serious need of
                        re-design and re-factoring". I'll wager that when you had the meeting,
                        people already knew that the code was - in your terms - hacked-up.

                        Another approach, instead of doing design up front speculatively - hoping
                        that it will reduce hacked-up code - what would happen if people who
                        recognize that they are creating hacked-up code would stop and clean it
                        then and there? What would happen if when we encounter bad code, we would
                        clean it then and there? What would happen if when we feel ourselves
                        writing ugly code, we stop and call a third part or a Quick Design Session.

                        Finally, you don't mention whether your team is practicing pair
                        programming. Is there any correlation between the poor code and
                        single-programmer work? Was the bulk of it produced by someone or someones
                        who need a little more help?

                        Don't get me wrong. I like a little bit of up front design. It keeps the
                        team on the same page, and helps people keep from going in the wrong
                        direction. But what you describe - hacked-up code needing redesign and
                        refactoring - doesn't sound like a design problem to me as much as it
                        sounds like a coding problem.

                        I could be wRONg, of course. ;->

                        R

                        Ronald E Jeffries
                        http://www.XProgramming.com
                        http://www.objectmentor.com

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

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

                        Ad-free courtesy of objectmentor.com
                      • Morris, Chris
                        ... BDUF all hinges on the ability of people to think of everything important before they see the code. Non-XPers say this is hard to do: On a typical project
                        Message 11 of 27 , Sep 28, 2000
                        • 0 Attachment
                          > What I am seeing is that a big objection -- or at least
                          > skeptisim -- from
                          > developers who are used to more "traditonal" methods of software
                          > development is that they see the lack of extensive
                          > architectural detail,
                          > and design sessions as leading to a hack job.

                          BDUF all hinges on the ability of people to think of everything important
                          before they see the code. Non-XPers say this is hard to do:

                          "On a typical project ... the customer can't reliably describe what is
                          needed before the code is written. ... The development process helps
                          customers better understand their own needs, and this is a major source of
                          requirements changes." (Steve McConnell, Code Complete, 30).

                          "[A]ccept the fact of change as a way of life, rather than an untoward and
                          annoying exception. ... the programmer delivers satisfaction of a user need
                          rather than any tangible product. And both the actual need and the user's
                          perception of that need will change as programs are built, tested, and
                          used." (Fred Brooks, The Mythical Man-Month, 117) .

                          XP is not anti-architecture or anti-design. XP does it as the project
                          develops, as the system itself is learned.

                          But the BDUF's seem to still think they can think of everything important up
                          front. As long as they believe that, XP seems foolish.

                          Chris
                        • Arrizza, John
                          There have been several arguments posted about this subject implying all you have to do is give someone a good argument and Bingo they ll change their minds. I
                          Message 12 of 27 , Sep 28, 2000
                          • 0 Attachment
                            There have been several arguments posted about this subject implying all you
                            have to do is give someone a good argument and Bingo they'll change their
                            minds.

                            I don't know that just doesn't sound right. My experience is that a good
                            rationale hardly ever leads to changed minds. I'm sure that the word
                            "compelling" is the key to the OPs problem not the word "argument".
                            Compelling refers to emotional response not to logic.

                            The OP said that the fellow he's trying to convince is intelligent,
                            open-minded and under a lot of pressure. A good rationale is not going to
                            cut the cake for this guy unless it addresses alleviating that pressure. I
                            think that the last thing a guy under pressure needs is a philosophical
                            argument.

                            John
                          • Victor
                            Here are a couple of thoughts. Their downside is that they require some work, reading. Kent Beck s book on Extreme Programming is not very long, is very
                            Message 13 of 27 , Sep 28, 2000
                            • 0 Attachment
                              Here are a couple of thoughts. Their downside is that they require some
                              work, reading.

                              Kent Beck's book on Extreme Programming is not very long, is very readable,
                              and answers to any argument I am aware of. The advantage is that everything
                              is written down, so you don't have to remember all the arguments as needed,
                              you just need to find the location where the discussion is. If you didn't
                              read it, read it. Ask your manager to read it. When both of you have read
                              it, it will be easier to have meaningful discussions.

                              If after all this, there are still unclear issues, you have here a
                              participatory audience ready to give a hand.

                              Victor




                              ----- Original Message -----
                              From: <wecaputo@...>
                              To: <extremeprogramming@egroups.com>
                              Sent: Wednesday, September 27, 2000 5:32 PM
                              Subject: [XP] XP as a hackarama


                              > To the tactful and compelling in the group:
                              >
                              > Ideas for dealing with the objection that XP results in hacked up design.
                              >
                              > What I am seeing is that a big objection -- or at least skeptisim -- from
                              > developers who are used to more "traditonal" methods of software
                              > development is that they see the lack of extensive architectural detail,
                              > and design sessions as leading to a hack job.
                              >
                              > What I am looking for is some compelling ways to meet (and hopefully
                              > overcome) these sorts of objections.
                              >
                              > I feel that the answer lies in the fact that big "perfect" architectures
                              > explore all kinds of possibilities -- on paper -- but don't in fact deal
                              > with any reality. XP overcomes this by evolving the architecture through
                              > such practices as Once and Only Once, and Do the Simplest Thing That Can
                              > Possibly Work, and MercilessRefactoring.
                              >
                              > What I want is an argument - not an XP lexicon. Those acronyms won't have
                              > any meaning to non-XP'rs, and so I think an argument without them is a
                              > better answer.
                              >
                              > BTW, I am a lousy salesman :)
                              >
                              > Thanks,
                              > Bill
                              >
                              >
                              > To Post a message, send it to: extremeprogramming@...
                              >
                              > To Unsubscribe, send a blank message to:
                              extremeprogramming-unsubscribe@...
                              >
                              > Ad-free courtesy of objectmentor.com
                              >
                              >
                            • Ron Jeffries
                              ... I m sorry you don t find the truth as I see it to be helpful. My strong opinion, based on lots of experience remains: almost all BIG refactorings, almost
                              Message 14 of 27 , Sep 28, 2000
                              • 0 Attachment
                                At 08:50 AM 9/28/00 -0700, Bruce Winegarden wrote:
                                >The rest of your comments appear to say if only we were doing XP "right" we
                                >wouldn't have this problem. That is an attitude on this list that is not
                                >helpful.

                                I'm sorry you don't find the truth as I see it to be helpful. My strong
                                opinion, based on lots of experience remains: almost all BIG refactorings,
                                almost all hacked-up code, can be avoided by paying close attention to the
                                little signals, and making small changes as soon as you detect that they
                                are needed.

                                This is a learning process. No one expects anyone to do it perfectly. G*d
                                knows _I_ don't do it perfectly. It may remain an elusive goal - or you may
                                reject the goal. I find that when I look at my hacked-up code - and there
                                is more than enough to look at - I can always see, in retrospect, how I
                                could have avoided the cruft, not by more design, but by being more
                                sensitive to the signs of problems, and more dedicated to keeping the code
                                clean.

                                >Our team has followed XP by the book as close as a new team could expect.
                                >Yes we do design in Interation planning, All production code written by a
                                >pair etc...
                                >
                                >There remains a very common XP problem of how to handle large refactorings
                                >that are the result of poor design decisions. Or shall I be XP politically
                                >correct? Emergent design that turns out to be expensive and difficult to
                                >extend. Politically incorrect = hacked up code.

                                I have no problem with the phrase "hacked up code". I've seen it and have
                                written it, and surely will again. I have a problem with the conclusion
                                that "more design" is the only thing that will avoid hacked up code. There
                                is another thing that reduces it, and that is to continually improve my
                                execution of the XP principles.

                                No one would expect an XP team to do perfectly in the first 8 weeks, or for
                                that matter, in the last. It is not given to us to be perfect, but we do
                                have the ability to try. To veer to the dark side after only 8 weeks,
                                however - that, young Skywalker, would be tragic. ;->

                                >Large refactorings cost customer velocity.
                                >How can we avoid them as much as possible?

                                I addressed that here and in my previous note that displeased you. Team
                                design in iteration planning, team design in quick design sessions,
                                increased sensitivity to poor code, and earlier refactoring are my
                                simplistic answers.

                                >When we don't how should we fix them?

                                If you hated the previous, you'll despise this: do large refactorings a
                                little bit at a time.

                                I could, of course, be wRONg. But I'm not insincere, nor am I
                                inexperienced. Take the advice for what it's worth, but remember it's the
                                advice of someone who has been there.

                                Ronald E Jeffries
                                http://www.XProgramming.com
                                http://www.objectmentor.com
                              • Victor
                                There is what I call emotional inertia . Sometimes it s a healthy defense mechanism. Under other circumstances it keeps us from making progress in our lives
                                Message 15 of 27 , Sep 28, 2000
                                • 0 Attachment
                                  There is what I call "emotional inertia". Sometimes it's a healthy defense
                                  mechanism. Under other circumstances it keeps us from making progress in our
                                  lives as fast as we could.

                                  The value of good arguments is that they prepare the terrain for future
                                  improved decisions.

                                  > .... I
                                  > think that the last thing a guy under pressure needs is a philosophical
                                  > argument.

                                  This is the problem of the guy under pressure, not to recognize that a good
                                  philosophical argument may be exactly what is needed. One way of helping
                                  this kind of person could be to help him/her to relax. People under
                                  pressure have a higher probability of making mistakes.

                                  Many times the main source of stress is internal. Maybe people that don't
                                  know how to handle pressure should not take a responsibility that includes
                                  pressure in the first place. However, I have found that a good, friendly
                                  but focused, personal, informal conversation over lunch can make a huge
                                  difference in the approach to problems. Many times what is required is just
                                  to get started with the first of such a series of conversations, and to keep
                                  them going as a reinforcement and support device.

                                  The friendly aspect is essential. It should not be a power game, but a
                                  tentative exploration of possibilities. The first effort should be that
                                  both people should feel in the same plane. Even the conversation should be
                                  heavily composed of professional issues, it should be nothing more than just
                                  a conversation, with no expectations, just an exchange of ideas. Let things
                                  settle down for a few days and if/when the other party comes up again with
                                  an old idea remind him/her (in a friendly way. This is very important, in a
                                  friendly way) of relevant aspects of your previous conversations, and ask
                                  innocently: "Do you think this would apply here?" .

                                  One of the big advantages of such one on one relaxed lunch conversations is
                                  that both participants give themselves the capability to listen to the
                                  other. To actually listen to the other. Sometimes one participant does not
                                  have this capability. I found that with patience and good humor even this
                                  can be overcome under certain circumstances.

                                  A word that Kent Beck uses in his XP book is "respect". Kent didn't invent
                                  this concept, but it's important that he wrote it down. It seems like many
                                  of us in the technical field could improve our capability of being
                                  respectful to self and others.

                                  Respect in this context means to listen empathetically to the other.
                                  Establishing an environment where people feel respected is essential for
                                  good communication in general and in these lunches in particular. Respect,
                                  empathy, and a friendly approach make a big difference in the stress level
                                  of the environment.

                                  Both great friendships and improved effectiveness may result from such a
                                  process. Pay attention I placed the word "friendships" first. Not many
                                  people in their death bed complain about having missed an opportunity to be
                                  more effective at work.
                                  People don't complain about having too many good friends either.

                                  Victor


                                  ----- Original Message -----
                                  From: "Arrizza, John" <john.arrizza@...>
                                  To: <extremeprogramming@egroups.com>
                                  Sent: Thursday, September 28, 2000 2:31 PM
                                  Subject: RE: [XP] XP as a hackarama


                                  > There have been several arguments posted about this subject implying all
                                  you
                                  > have to do is give someone a good argument and Bingo they'll change their
                                  > minds.
                                  >
                                  > I don't know that just doesn't sound right. My experience is that a good
                                  > rationale hardly ever leads to changed minds. I'm sure that the word
                                  > "compelling" is the key to the OPs problem not the word "argument".
                                  > Compelling refers to emotional response not to logic.
                                  >
                                  > The OP said that the fellow he's trying to convince is intelligent,
                                  > open-minded and under a lot of pressure. A good rationale is not going to
                                  > cut the cake for this guy unless it addresses alleviating that pressure. I
                                  > think that the last thing a guy under pressure needs is a philosophical
                                  > argument.
                                  >
                                  > John
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to:
                                  extremeprogramming-unsubscribe@...
                                  >
                                  > Ad-free courtesy of objectmentor.com
                                  >
                                  >
                                • Bruce Winegarden
                                  Thank you for your well considered response. Overall our team is very pleased with the progress we have made using XP. We are applying feedback principles to
                                  Message 16 of 27 , Sep 28, 2000
                                  • 0 Attachment
                                    Thank you for your well considered response. Overall our team is very
                                    pleased with the progress we have made using XP. We are applying feedback
                                    principles to adapt and learn from our experiences. Many of the other XP
                                    teams we talk to have the same problem of figuring out how to deal with a
                                    backlog of accumulated refactorings.

                                    You could be even more helful by expanding on a couple of your points.

                                    1> almost all hacked-up code, can be avoided by paying close attention to
                                    the
                                    little signals,

                                    Q. What are some signals we should watch for?

                                    2> do large refactorings a little bit at a time.

                                    Q. Please provide some suggestions on how to do this. We have Martin
                                    Fowler's Refactoring book and are rapidly gaining refactoring proficency.
                                    It's nice to have a map for how to take small steps from one code pattern to
                                    another without breaking things. There is no similar road map for big
                                    refactorings. I'm guessing you may say something like it's really just a
                                    bunch of small refactorings. It seems like this would still require some
                                    advance planning (dare I say design) to figure out which small refactorings
                                    and what order to perform them in.

                                    Bruce Winegarden
                                    Product Sight
                                    (425) 467-7117


                                    -----Original Message-----
                                    From: Ron Jeffries [mailto:ronjeffries@...]
                                    Sent: Thursday, September 28, 2000 3:21 PM
                                    To: extremeprogramming@egroups.com
                                    Subject: RE: [XP] XP as a hackarama


                                    At 08:50 AM 9/28/00 -0700, Bruce Winegarden wrote:
                                    >The rest of your comments appear to say if only we were doing XP "right" we
                                    >wouldn't have this problem. That is an attitude on this list that is not
                                    >helpful.

                                    I'm sorry you don't find the truth as I see it to be helpful. My strong
                                    opinion, based on lots of experience remains: almost all BIG refactorings,
                                    almost all hacked-up code, can be avoided by paying close attention to the
                                    little signals, and making small changes as soon as you detect that they
                                    are needed.

                                    This is a learning process. No one expects anyone to do it perfectly. G*d
                                    knows _I_ don't do it perfectly. It may remain an elusive goal - or you may
                                    reject the goal. I find that when I look at my hacked-up code - and there
                                    is more than enough to look at - I can always see, in retrospect, how I
                                    could have avoided the cruft, not by more design, but by being more
                                    sensitive to the signs of problems, and more dedicated to keeping the code
                                    clean.

                                    >Our team has followed XP by the book as close as a new team could expect.
                                    >Yes we do design in Interation planning, All production code written by a
                                    >pair etc...
                                    >
                                    >There remains a very common XP problem of how to handle large refactorings
                                    >that are the result of poor design decisions. Or shall I be XP politically
                                    >correct? Emergent design that turns out to be expensive and difficult to
                                    >extend. Politically incorrect = hacked up code.

                                    I have no problem with the phrase "hacked up code". I've seen it and have
                                    written it, and surely will again. I have a problem with the conclusion
                                    that "more design" is the only thing that will avoid hacked up code. There
                                    is another thing that reduces it, and that is to continually improve my
                                    execution of the XP principles.

                                    No one would expect an XP team to do perfectly in the first 8 weeks, or for
                                    that matter, in the last. It is not given to us to be perfect, but we do
                                    have the ability to try. To veer to the dark side after only 8 weeks,
                                    however - that, young Skywalker, would be tragic. ;->

                                    >Large refactorings cost customer velocity.
                                    >How can we avoid them as much as possible?

                                    I addressed that here and in my previous note that displeased you. Team
                                    design in iteration planning, team design in quick design sessions,
                                    increased sensitivity to poor code, and earlier refactoring are my
                                    simplistic answers.

                                    >When we don't how should we fix them?

                                    If you hated the previous, you'll despise this: do large refactorings a
                                    little bit at a time.

                                    I could, of course, be wRONg. But I'm not insincere, nor am I
                                    inexperienced. Take the advice for what it's worth, but remember it's the
                                    advice of someone who has been there.

                                    Ronald E Jeffries
                                    http://www.XProgramming.com
                                    http://www.objectmentor.com

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

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

                                    Ad-free courtesy of objectmentor.com
                                  • Ron Jeffries
                                    ... Yes. We all find dealing with such a backlog very problematical. We all know what clean it up later means. ... I ll assume there s a missing p there,
                                    Message 17 of 27 , Sep 28, 2000
                                    • 0 Attachment
                                      At 08:01 PM 9/28/00 -0700, Bruce Winegarden wrote:
                                      >Thank you for your well considered response. Overall our team is very
                                      >pleased with the progress we have made using XP. We are applying feedback
                                      >principles to adapt and learn from our experiences. Many of the other XP
                                      >teams we talk to have the same problem of figuring out how to deal with a
                                      >backlog of accumulated refactorings.

                                      Yes. We all find dealing with such a backlog very problematical. We all
                                      know what "clean it up later" means.

                                      >You could be even more helful by expanding on a couple of your points.

                                      I'll assume there's a missing "p" there, not a missing "l". ;->

                                      >1> almost all hacked-up code, can be avoided by paying close attention to
                                      >the
                                      >little signals,
                                      >
                                      >Q. What are some signals we should watch for?

                                      I don't know, because I don't know which ones you are missing. All the code
                                      smells start small. If I were there, I'd take a look at the hacked up code
                                      we had, think back a few days to how we started on it, maybe even roll the
                                      versions back that far, and look to see where it started to go awry. That
                                      would be the sort of clue I'd look for in the future.

                                      We're all sensitive to different things, insensitive to different things.
                                      Are big procedural methods our bane? Watch for them - even check them
                                      mechanically. Do we wind up with lots of duplicate code that needs to be
                                      undone? Be more alert for that.

                                      What kinds of things have we found "wrong" with the code we don't like?
                                      What were the early signs that we missed? How can we catch them earlier?

                                      >2> do large refactorings a little bit at a time.
                                      >
                                      >Q. Please provide some suggestions on how to do this. We have Martin
                                      >Fowler's Refactoring book and are rapidly gaining refactoring proficency.
                                      >It's nice to have a map for how to take small steps from one code pattern to
                                      >another without breaking things. There is no similar road map for big
                                      >refactorings. I'm guessing you may say something like it's really just a
                                      >bunch of small refactorings. It seems like this would still require some
                                      >advance planning (dare I say design) to figure out which small refactorings
                                      >and what order to perform them in.

                                      I honestly don't know how I do it. I do know that I usually can, and that
                                      in retrospect I can often see how I could have done better. So I am
                                      confident that by wanting badly enough to do it incrementally, we usually can.

                                      C3's biggest blob refactoring was the time we had to change all the
                                      deductions in the payroll from negative numbers added into the check to
                                      positive numbers subtracted from the check. We did it over a period of a
                                      week or so, and let the unit tests faile for a while. It was scary but
                                      since we had the tests we knew that when they all ran again, everything
                                      would be OK.

                                      In retrospect, I suspect that we should have created a bunch of new
                                      classes, positive deduction, negative deduction, etc, and caused them to
                                      know how to add themselves up. We could have converted to these
                                      incrementally, because the decision to add or subtract would have gone into
                                      the deduction object.

                                      I'm no longer sure whether this would have worked, but think it would have.
                                      We survived the big refactoring - and so will you. But we felt the pain,
                                      and I don't like pain, so I try never to do it again. There are two key
                                      approaches: note problems early, and when you have big problems, find lots
                                      of little solutions.

                                      Regards,

                                      Ronald E Jeffries
                                      http://www.XProgramming.com
                                      http://www.objectmentor.com
                                    • Jim Little
                                      From: Bruce Winegarden ... we ... I ve noticed this too. Another unfortunate tendancy of the is list to take someone s
                                      Message 18 of 27 , Sep 28, 2000
                                      • 0 Attachment
                                        From: "Bruce Winegarden" <bruce.winegarden@...>

                                        > The rest of your comments appear to say if only we were doing XP "right"
                                        we
                                        > wouldn't have this problem. That is an attitude on this list that is not
                                        > helpful.

                                        I've noticed this too. Another unfortunate tendancy of the is list to take
                                        someone's negative experience and blame it on "poor design." Although it
                                        may be true (it certainly has been in my case) I've never seen anybody
                                        discuss their design in enough detail for anybody else to be able to truly
                                        judge it.

                                        Less dogmatism and more admissions of weaknesses (and how they have been
                                        fixed!) would be helpful, IMO.

                                        > Our team has followed XP by the book as close as a new team could expect.
                                        > Yes we do design in Interation planning, All production code written by a
                                        > pair etc...
                                        >
                                        > There remains a very common XP problem of how to handle large refactorings
                                        > that are the result of poor design decisions.

                                        Our team is also fairly new to XP (less than a year) and also occasionally
                                        sees large refactorings. All of them have been due to our overall
                                        architecture changing as team members see new ways to simplify it. None of
                                        them "had" to be done; they just seemed to promise better and
                                        easier-to-write code.

                                        The way we've dealt with these is not to create a story for them and do them
                                        in one fell swoop. Instead, we identify the direction we want to go and
                                        then start going there incrementally. We start by marking all of the "old"
                                        way of doing things as deprecated. We have a rule that any class we work on
                                        can't have deprecation warnings when we're done. Thus the refactoring
                                        occurs piecemeal as we work on the code, with the heavily-trafficked code
                                        being fixed first.

                                        This does lead to multiple architecturual visions existing simultaneously
                                        within the code. That hasn't been a problem so far. I like Joshua
                                        Kerievsky's idea of having a pile of refactoring cards in the center of the
                                        table as a visible metric of how ugly the code is, but we haven't tried that
                                        yet. (One problem we'd have to watch out for is the temptation of putting a
                                        refactoring on a card instead of just biting the bullet and doing it.)

                                        The technique of marking things deprecated also works well when you want to
                                        rename a method but not go around and change all the code that uses that
                                        method.

                                        Jim

                                        ---
                                        Contractors wanted for January 2001 project in Portland, OR.
                                        We'll be utilizing full XP and Java. Experience with Java & XP is optional.
                                        Email background and bill rate if you're interested.
                                      • Jim Little
                                        From: Arrizza, John ... a ... their ... Whereas the our position as XP ers is just the opposite: It comes from fear and egotism.
                                        Message 19 of 27 , Sep 28, 2000
                                        • 0 Attachment
                                          From: "Arrizza, John" <john.arrizza@...>

                                          > > they see the lack of extensive
                                          > > architectural detail, and design sessions as leading to a hack job.
                                          >
                                          > Their position comes from egotism and fear. They fear that they will make
                                          a
                                          > mistake in the architecture and won't be able to fix it later unless they
                                          > analyze everything up front. Egotism because they think that they *can*
                                          > analyze everything up front. So whatever tack you take it must appease
                                          their
                                          > egotism and fear.

                                          Whereas the our position as XP'ers is just the opposite: It comes from fear
                                          and egotism. We fear that we can't possibly be smart enough to think of
                                          everything in the architecture and that all our mistakes will add up to a
                                          huge mess. Egotism because we think we can hold off and just fix problems
                                          when they arise.

                                          ;)

                                          Jim

                                          ---
                                          Contractors wanted for January 2001 project in Portland, OR.
                                          We'll be utilizing full XP and Java. Experience with Java & XP is optional.
                                          Email background and bill rate if you're interested.
                                        • Ron Jeffries
                                          ... Outstanding! Exactly in line with XP (as I see it). Wonderful! Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
                                          Message 20 of 27 , Sep 29, 2000
                                          • 0 Attachment
                                            At 10:29 PM 9/28/00 -0600, Jim Little wrote:
                                            >The way we've dealt with these is not to create a story for them and do them
                                            >in one fell swoop. Instead, we identify the direction we want to go and
                                            >then start going there incrementally. We start by marking all of the "old"
                                            >way of doing things as deprecated. We have a rule that any class we work on
                                            >can't have deprecation warnings when we're done. Thus the refactoring
                                            >occurs piecemeal as we work on the code, with the heavily-trafficked code
                                            >being fixed first.

                                            Outstanding! Exactly in line with XP (as I see it). Wonderful!

                                            Ronald E Jeffries
                                            http://www.XProgramming.com
                                            http://www.objectmentor.com
                                          • Ron Jeffries
                                            ... This one I d just do immediately, in almost any environment. Are you practicing collective ownership? Would integrating MORE often help? R Ronald E
                                            Message 21 of 27 , Sep 29, 2000
                                            • 0 Attachment
                                              At 10:29 PM 9/28/00 -0600, Jim Little wrote:
                                              >The technique of marking things deprecated also works well when you want to
                                              >rename a method but not go around and change all the code that uses that
                                              >method.

                                              This one I'd just do immediately, in almost any environment. Are you
                                              practicing collective ownership? Would integrating MORE often help?

                                              R



                                              Ronald E Jeffries
                                              http://www.XProgramming.com
                                              http://www.objectmentor.com
                                            • Arrizza, John
                                              ... agreed, but you ve got to be ready to change. That readiness is caused either by a big bang external stimulus or a long series small stimuli. Your idea of
                                              Message 22 of 27 , Sep 29, 2000
                                              • 0 Attachment
                                                > -----Original Message-----
                                                > From: Victor [mailto:vgoldberg@...]

                                                > The value of good arguments is that they prepare the terrain
                                                > for future improved decisions.
                                                agreed, but you've got to be ready to change. That readiness is caused
                                                either by a big bang external stimulus or a long series small stimuli. Your
                                                idea of "Emotional interia" is "not ready to change."

                                                > Many times the main source of stress is internal. Maybe
                                                > people that don't know how to handle pressure should not take a
                                                > responsibility that includes pressure in the first place.
                                                Very good point! but promotions are meted out for a variety of reasons not
                                                necessarily for an ability to handle pressure. So you have to deal with your
                                                bosses emotional baggage et al to get things across.

                                                > The friendly aspect is essential. It should not be a power
                                                > game, but a tentative exploration of possibilities. The first effort
                                                > should be that both people should feel in the same plane. Even the
                                                > conversation should be heavily composed of professional issues, it should
                                                > be nothing more than just a conversation, with no expectations, just an
                                                > exchange of ideas.
                                                ...
                                                > Respect in this context means to listen empathetically to the other.

                                                I agree. Perhaps just listening to the other person would let them relax.
                                                Also, in the course of their talking they may let you know why they feel the
                                                pressure. It's probably not "Oh No! I don't have a development methodology!"
                                                and more like "I told my wife when I got this promotion that I'd be home
                                                before 8PM every night and I'm working till 10PM every night instead."

                                                <other good points snipped>
                                                The best book to recommend here would be "How to Win Friends and Influence
                                                People." Smaltzy title but effective techniques within. Basically Carnegie
                                                and you agree on respect, friendship, etc.

                                                (BTW tried to read HtWFaIP but had a gag reflex? Try Gerald Weinberg's book
                                                "Becoming a Technical Leader" first, he explains very nicely why you had a
                                                gag reflex.)

                                                John
                                              • Kay Johansen
                                                ... we work on ... Are you just marking this with a comment? ... optional. Are you going to Portland, Jim? Cool. -Kay
                                                Message 23 of 27 , Sep 29, 2000
                                                • 0 Attachment
                                                  --- In extremeprogramming@egroups.com, "Jim Little" <jiml@i...> wrote:
                                                  > We start by marking all of the "old"
                                                  > way of doing things as deprecated. We have a rule that any class
                                                  we work on
                                                  > can't have deprecation warnings when we're done.

                                                  Are you just marking this with a comment?

                                                  > ---
                                                  > Contractors wanted for January 2001 project in Portland, OR.
                                                  > We'll be utilizing full XP and Java. Experience with Java & XP is
                                                  optional.

                                                  Are you going to Portland, Jim? Cool.

                                                  -Kay
                                                • Jim Little
                                                  From: Ron Jeffries ... to ... You re probably right. It s not an integration issue, just a laziness issue. A good refactoring
                                                  Message 24 of 27 , Sep 29, 2000
                                                  • 0 Attachment
                                                    From: "Ron Jeffries" <ronjeffries@...>

                                                    > At 10:29 PM 9/28/00 -0600, Jim Little wrote:
                                                    > >The technique of marking things deprecated also works well when you want
                                                    to
                                                    > >rename a method but not go around and change all the code that uses that
                                                    > >method.
                                                    >
                                                    > This one I'd just do immediately, in almost any environment. Are you
                                                    > practicing collective ownership? Would integrating MORE often help?

                                                    You're probably right. It's not an integration issue, just a "laziness"
                                                    issue. A good refactoring browser would go a long way here. (I've tried
                                                    JRefactory, but I don't like that it reformats the code.)

                                                    Jim

                                                    ---
                                                    Contractors wanted for January 2001 project in Portland, OR.
                                                    We'll be utilizing full XP and Java. Experience with Java & XP is
                                                    optional.
                                                  • wconrad@sprintmail.com
                                                    Deprecation works the same in VAJ. Methods and classes which trigger the deprecated warning show up with a yellow warning sign in the IDE. Wayne Conrad
                                                    Message 25 of 27 , Oct 1, 2000
                                                    • 0 Attachment
                                                      Deprecation works the same in VAJ. Methods and classes which trigger the
                                                      deprecated warning show up with a yellow "warning" sign in the IDE.
                                                      Wayne Conrad
                                                    • Bruce Winegarden
                                                      ... we work on ... What a great tip! Can anyone explan how you mark methods or classes as depricated so that Java compiler will give us depricated warnings?
                                                      Message 26 of 27 , Oct 1, 2000
                                                      • 0 Attachment
                                                        Jim Little wrote:
                                                        > We start by marking all of the "old"
                                                        > way of doing things as deprecated. We have a rule that any class
                                                        we work on
                                                        > can't have deprecation warnings when we're done.

                                                        What a great tip!
                                                        Can anyone explan how you mark methods or classes as depricated so that Java
                                                        compiler will give us depricated warnings?
                                                        BTW, we are using IBM's VisualAge for Java.

                                                        Bruce Winegarden
                                                        Product Sight
                                                        (425) 467-7117


                                                        -----Original Message-----
                                                        From: Kay Johansen [mailto:kay@...]
                                                        Sent: Friday, September 29, 2000 12:00 PM
                                                        To: extremeprogramming@egroups.com
                                                        Subject: [XP] Re: XP as a hackarama


                                                        --- In extremeprogramming@egroups.com, "Jim Little" <jiml@i...> wrote:
                                                        > We start by marking all of the "old"
                                                        > way of doing things as deprecated. We have a rule that any class
                                                        we work on
                                                        > can't have deprecation warnings when we're done.

                                                        Are you just marking this with a comment?

                                                        > ---
                                                        > Contractors wanted for January 2001 project in Portland, OR.
                                                        > We'll be utilizing full XP and Java. Experience with Java & XP is
                                                        optional.

                                                        Are you going to Portland, Jim? Cool.

                                                        -Kay



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

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

                                                        Ad-free courtesy of objectmentor.com
                                                      • Jim Little
                                                        From: Bruce Winegarden ... Java ... I don t know how you would do this in VAJ, but the basic idea is that you add a
                                                        Message 27 of 27 , Oct 1, 2000
                                                        • 0 Attachment
                                                          From: "Bruce Winegarden" <bruce.winegarden@...>

                                                          > Jim Little wrote:
                                                          > > We start by marking all of the "old"
                                                          > > way of doing things as deprecated. We have a rule that any class
                                                          > > we work on can't have deprecation warnings when we're done.
                                                          >
                                                          > What a great tip!
                                                          > Can anyone explan how you mark methods or classes as depricated so that
                                                          Java
                                                          > compiler will give us depricated warnings?
                                                          > BTW, we are using IBM's VisualAge for Java.

                                                          I don't know how you would do this in VAJ, but the basic idea is that you
                                                          add a @deprecated doc-comment to your class or method:

                                                          /** @deprecated use the Bar class instead */
                                                          class Foo { ... }

                                                          class Bar {
                                                          /** @deprecated this method has been moved to the Baz class */
                                                          void foodleIt() { ... }
                                                          }

                                                          Jim

                                                          ---
                                                          Contractors wanted for January 2001 project in Portland, OR.
                                                          We'll be utilizing full XP and Java. Experience with Java & XP is
                                                          optional.
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.