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

Re: How do you eat an elephant? (XP on a large project)

Expand Messages
  • Jeff Grigg
    Q: How do you eat an elephant? A: With a Cherry Coke, and a side of fries. ;- ... You can t fight the tide. King Canute demonstrated that. ;- (OK, tight.
    Message 1 of 9 , May 1, 2004
      Q: How do you eat an elephant?
      A: With a Cherry Coke, and a side of fries.
      ;->

      --- "Orhan Kalayci" <orhan.kalayci@n...> wrote:
      > There is a "big" project (initial estimation: about 40
      > weeks long with around 20 programmers)
      >
      > Requirements are already documented largely in paper.
      > The schedule is very tide.

      You can't fight the tide. King Canute demonstrated that. ;->

      (OK, "tight." ;-)

      I was on a project a few years ago... When all the parties called
      their lawyers and sued each other, the question of the day
      was, "When did you first realize that the project was in
      trouble?" "Well," I said, "during my first phone interview to join
      the project, the project manager said, 'We know the schedule is
      tight, but we think we can make it.' I knew at that point that they
      were in deep trouble, and would not make the schedule." [This is
      real life; not a made up story.]


      > The system is so large that people cannot believe in that
      > we cannot begin coding before designing all the system.

      See, now there's a good argument for doing XP. XP starts with
      coding, and does not do Big Design Up-Front.

      (For such a large team, however, you will need some overall
      coordination and planning.)


      > (We cannot afford big refactorings during the project,
      > to minimize this, all the system should be designed at
      > the beginning.)

      Your remarks up this point all tell me that the project is doomed.
      XP can help. With a commitment to the XP practices, you can be sure
      to produce some useful system by the given deadline. It won't do
      everything they wished for, nor everything in the specs, but if you
      do it right, the system will do all the most important things that
      the business needs.

      Now as to refactoring...
      To avoid large refactorings, you must aggressively pursue small
      refactorings.

      Also, with a high level of code reuse (meaning very little violation
      of Once And Only Once), there will be no large refactorings. It's
      rampant duplication and lack of code reuse that forces you into the
      largest and most distributed of refactorings.


      > If you think in terms of XP practices only, it seems a
      > very valid claim saying it is less risky to begin the
      > programming after designing all the system.

      As others mentioned, you have that backwards.

      > The question is:
      > 1. Do you think whether XP practices (namely, simple
      > design) can be applied to this project?

      Do you have the support of your peers and the project leadership?

      > 2. Do you believe in that Object Oriented Design (OOD)
      > gives XP practices the power that although the whole
      > system is not designed at the beginning thanks to
      > OOD it is possible to begin small (without designing
      > the whole system but at the same time no enormous
      > refactoring will be required during the project?

      OOA/OOD/OOP (Object-Oriented Analysis/Design/Programming) is not the
      issue. XP succeeds with simple and emergent design due to
      refactoring and testing. "OOx" has little to do with it, beyond the
      fact that object oriented programming languages give us powerful
      tools for abstraction and reuse.

      Yes, constant refactoring will be required of the project. That's
      how Test Driven Development (TDD) works. However, if you do your
      job well, "large scary risky" refactorings will be rare to
      nonexistent.

      > 3. How about performing XP without OOD - do you think
      > it is still economic (preferable) compared to waterfall.

      XP doesn't do "OOD" in the conventionally understood sense.

      XP is better than waterfall.
      XP is better than incremental delivery.
      XP is true iterative development.
    • Laurent Bossavit
      ... I don t understand how you can help a project which is doomed. It seems to me that a project which starts out under a veil of self- delusion will
      Message 2 of 9 , May 1, 2004
        Jeff:

        > Your remarks up this point all tell me that the project is doomed. XP
        > can help.

        I don't understand how you can "help" a project which is doomed. It
        seems to me that a project which starts out under a veil of self-
        delusion will inevitably lead to a crisis, no matter how many well-
        meaning attempts are made to infuse it with some sense of direction.

        Cheers,

        -[Laurent]-
        If a program is useless, it will have to be documented.
      • Phlip
        ... 4. How will you make sure that each part of each user story is needed? The answer is to colocate a Customer, and give them the authority to remove every
        Message 3 of 9 , May 1, 2004
          Orhan Kalayci wrote:

          > There is a "big" project (initial estimation: about
          > 40 weeks long
          > with around 20 programmers)
          >
          > Requirements are already documented largely in
          > paper.
          > The schedule is very tide.
          >
          > The system is so large that people cannot believe in
          > that we cannot
          > begin coding before designing all the system. (We
          > cannot afford big
          > refactorings during the project, to minimize this,
          > all the system
          > should be designed at the beginning.)
          >
          > If you think in terms of XP pratices only, it seems
          > a very valid
          > claim saying it is less risky to begin the
          > programming after
          > designing all the system.
          >
          > The question is:
          > 1. Do you think whether XP practices (namely,
          > simple design) can be
          > applied to this project?
          >
          > 2. Do you believe in that Object Oriented Design
          > (OOD) gives XP
          > pratices the power that although the whole system is
          > not designed at
          > the beginning thanks to OOD it is possible to begin
          > small (without
          > designing the whole system but at the same time no
          > anourmous
          > refactoring will be required during the project?
          >
          > 3. How about performing XP without OOD - do you
          > think it is still
          > economic (preferable) compared to waterfall.

          4. How will you make sure that each part of each user
          story is needed?

          The answer is to colocate a Customer, and give them
          the authority to remove every small detail in each
          user story that they figure is not needed. "Scope
          Control".

          This tightens the schedule if it's allowed to ripple
          up. But you don't know if the design concept you are
          planning might support features that deserve to be
          nixed.

          And refactoring is not re-work. It's another way to go
          faster.

          So put them together, and your crew is asking for ways
          to blunt the effect of scope control.

          Eat a baby elephant.

          =====
          Phlip
          http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces




          __________________________________
          Do you Yahoo!?
          Win a $20,000 Career Makeover at Yahoo! HotJobs
          http://hotjobs.sweepstakes.yahoo.com/careermakeover
        • Jeff Grigg
          ... Yes. Further, there is the very strong possibility that the leadership of the project will be so overwhelmed with the urgency of making fantastic progress
          Message 4 of 9 , May 1, 2004
            > Jeff sayz:
            >> Your remarks up this point all tell me that the project
            >> is doomed. XP can help.

            --- "Laurent Bossavit" <laurent@b...> wrote:
            > I don't understand how you can "help" a project which is
            > doomed. It seems to me that a project which starts out
            > under a veil of self-delusion will inevitably lead to a
            > crisis, no matter how many well-meaning attempts are made
            > to infuse it with some sense of direction.

            Yes. Further, there is the very strong possibility that the
            leadership of the project will be so overwhelmed with the urgency of
            making fantastic progress against the largely unreachable goals that
            they will be completely unable to make significant progress: The
            old, "I don't have time to sharpen my axe; don't you see how many
            trees I have to cut?!?!?!?"


            I'm thinking that on a doomed project, an iterative approach will at
            least produce some usable product. And with the right politics,
            they'll be able to call that a complete success. ;->
          • CORUM, M E [AG/1000]
            First, let me say that there have been many excellent answers on this thread. I d like to add some information. The term big is relative. To me, the 40
            Message 5 of 9 , May 2, 2004
              First, let me say that there have been many excellent answers on this
              thread. I'd like to add some information. The term "big" is relative.
              To me, the 40 weeks doesn't necessarily make the project "big", maybe
              medium. The 20 programmers is also a medium number. For others, both
              of those numbers would be considered tiny if they are used to projects
              with 200 programmers and 3 to 5 years.

              It sounds like you have a concern about Emergent Design verus Big Design
              Up Front. It sounds like you or your colleagues believe more in the
              latter or perhaps have the most experience with the latter. I recently
              made a presentation at a local user group on the subject of Emergent
              Design (or Emergent Architecture). I gave some numbers from the early
              iterations of several projects. If you look at the iterations as projects
              themselves, they would be considered small but several of them are part of
              larger projects that continued for several years. In one case, a COCOMO II
              estimate for the first iteration of a larger projects said that this
              iteration would require 14.5 months to complete with 7 people ramping up to
              12 people at the peak. The project was completed (using XP) in 4.5 months
              (not 14.5 but 4.5) with 6 people.

              In the past, when I had used COCOMO II to compare projects after the fact, it
              had always nailed the timeline down to the week but had over-estimated the
              number of programmers needed by roughly 20%. Based on that, we should have
              used from 5 to 10 people for 14.5 months. The combination of all the XP
              practices that we did contributed to shortening the timeline dramatically and
              to at least holding down the number of people necessary to complete the
              iteration. Emergent Architecture/Design was a big part of that as this
              customer was creating his business process as he was specifying the needs for
              the software. Therefore, there was a large amount of change over time. Some
              requirements went back and forth between options more than three times during
              this period. I really wish I had kept track of the "agility metric" at that
              time but I didn't. I will in the future.

              In one of the early projects I presented on, there were a large number of
              major architectural changes required during the course of the project. One
              example of that is that a complex security scheme was needed. We knew that
              we needed something at the beginning but the customer wanted us to wait until
              they got all the requirements together for security (which included inputs
              from Legal). We got the security requirements 2 months after the project had
              gone into production for the subset of people that had high security and could
              see/do anything. At the beginning, I told the customer it could take a month
              just to code (and re-work) the software to handle the security if we waited
              so long to do it (and another month of testing). This was because the customer
              didn't want to pay for speculatively putting in the hooks for a security framework
              at the beginning because the possibility existed that the security might not be
              needed. The customer couldn't really control when they would get the final
              requirements so we moved on. Based on that estimate, it should have taken well
              over two months (perhaps almost three) to go from receiving the security requirements
              to production delivery. When the requirements came through, we got the job done in
              5 days with a team of 2 people. We used an additional 3 days to fully automate
              acceptance testing. We were being extra careful due to the legal implications.
              The final delivery to production was just under a month from when we received the
              requirements. I consider this to be a very good result and largely due to the
              XP practices.

              That incident, along with many others like it, made me a believer in the concept of
              Emergent Architecture. You won't know for sure until you try it. There is some
              risk involved. This is true whenever you try something new and different.

              One last thing. I think that OO and design skills are very important. XP gave me
              a much deeper understanding of OO and design concepts. The fact that XP has you
              designing in small increments every day means that you are practicing design all the
              time. You get rapid feedback about whether your design is good or bad and you are
              able to fix bad things quickly and get the feedback that it is better.

              Mike Corum

              -----Original Message-----
              >Message: 8
              > Date: Sat, 01 May 2004 12:24:46 -0000
              > From: "Orhan Kalayci" <orhan.kalayci@...>
              >Subject: How do you eat an elephant?
              >
              >Dear all,
              >
              >There is a "big" project (initial estimation: about 40 weeks long
              >with around 20 programmers)
              >
              >Requirements are already documented largely in paper.
              >The schedule is very tide.
              >
              >The system is so large that people cannot believe in that we cannot
              >begin coding before designing all the system. (We cannot afford big
              >refactorings during the project, to minimize this, all the system
              >should be designed at the beginning.)
              >
              >If you think in terms of XP pratices only, it seems a very valid
              >claim saying it is less risky to begin the programming after
              >designing all the system.
              >
              vThe question is:
              >1. Do you think whether XP practices (namely, simple design) can be
              >applied to this project?
              >
              >2. Do you believe in that Object Oriented Design (OOD) gives XP
              >pratices the power that although the whole system is not designed at
              >the beginning thanks to OOD it is possible to begin small (without
              >designing the whole system but at the same time no anourmous
              >refactoring will be required during the project?
              >
              >3. How about performing XP without OOD - do you think it is still
              >economic (preferable) compared to waterfall.
              >
              >Thank you in advance,
              >Orhan Kalayci
            • Ilja Preuss
              ... Why? Didn t you just delay critical feedback? ... What language will you be using? A procedural? Declarative? Functional? Cheers, Ilja
              Message 6 of 9 , May 3, 2004
                Orhan Kalayci wrote:

                > If you think in terms of XP pratices only, it seems a very valid
                > claim saying it is less risky to begin the programming after
                > designing all the system.

                Why? Didn't you just delay critical feedback?

                > 3. How about performing XP without OOD - do you think it is still
                > economic (preferable) compared to waterfall.

                What language will you be using? A procedural? Declarative? Functional?

                Cheers, Ilja
              Your message has been successfully submitted and would be delivered to recipients shortly.