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

How do you eat an elephant?

Expand Messages
  • Orhan Kalayci
    Dear all, There is a big project (initial estimation: about 40 weeks long with around 20 programmers) Requirements are already documented largely in paper.
    Message 1 of 9 , May 1, 2004
    • 0 Attachment
      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.

      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.

      Thank you in advance,
      Orhan Kalayci


      ---------------------------------------------------------------------
      -----------

      Orhan Kalaycý, Genel Müdür,

      Nitelik Yazýlým Danýþmanlýk Ltd

      Tübitak Marmara Araþtýrma Merkezi

      Teknoloji Geliþtirme Bölgesi

      No: 10 Gebze 41470 Kocaeli

      Tel: 0262 646 3045 / 3011

      Tel: 0212 365 1033

      Fax: 0212 365 1034

      orhan.kalayci@...

      www.nitelik.net


      ---------------------------------------------------------------------
      -----------
    • Ron Jeffries
      ... The first XP project was over 200 weeks, with 14 programmers ... over 50 weeks before the first commercial deployment. ... People shouldn t do what they
      Message 2 of 9 , May 1, 2004
      • 0 Attachment
        On Saturday, May 1, 2004, at 8:24:46 AM, Orhan Kalayci wrote:

        > There is a "big" project (initial estimation: about 40 weeks long
        > with around 20 programmers)

        The first XP project was over 200 weeks, with 14 programmers ... over 50
        weeks before the first commercial deployment.

        > 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.)

        People shouldn't do what they don't believe in. On the other hand, up front
        design is not the only way, or even the best way, to avoid large
        refactorings.

        > 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.

        It doesn't seem valid to me. How many weeks of the 40 do people propose to
        spend designing all the system? How many of the team of 20 will do this?

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

        You haven't told us what the project is. But I think that the XP practices
        can be applied to every proejct I've ever done in the past more than 40
        years ...

        > 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?

        Object oriented languages help. I'm not sure what you mean by OOD.

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

        Yes.

        Ron Jeffries
        www.XProgramming.com
        Discontinue reading if rash, irritation, redness, or swelling develops.
        Especially irritation.
      • Keith Ray
        ... You re doomed already if management thinks it s going to be done in less than 80 weeks. Hofstadter s Law: It always takes longer than you think, even when
        Message 3 of 9 , May 1, 2004
        • 0 Attachment
          On May 1, 2004, at 5:24 AM, Orhan Kalayci wrote:

          > There is a "big" project (initial estimation: about 40 weeks long
          > with around 20 programmers)

          You're doomed already if management thinks it's going to be done in
          less than 80 weeks.

          Hofstadter's Law: It always takes longer than you think, even when you
          take Hofstadter's Law into account. (Douglas Hofstadter)

          Did the 20 programmers got together and create that 40-week estimate?
          Or did the estimate come from someone who's not doing the work? Did
          they calibrate that estimate by doing some some amount of the work
          required within one or two iterations?

          Quite possibly you could get 80% of the requirements done in 40 weeks,
          if you used the best 10 programmers (and 4 or 5 testers) and did all of
          the XP practices well. With 20 programmers [how many testers?], no
          prior knowledge of XP within the company, and a tendency to do
          "waterfall", I would not be expect the project to do well.

          --
          C. Keith Ray
          <http://homepage.mac.com/keithray/blog/index.html>
          <http://homepage.mac.com/keithray/xpminifaq.html>
          <http://homepage.mac.com/keithray/resume2.html>



          [Non-text portions of this message have been removed]
        • 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 4 of 9 , May 1, 2004
          • 0 Attachment
            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 5 of 9 , May 1, 2004
            • 0 Attachment
              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 6 of 9 , May 1, 2004
              • 0 Attachment
                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 7 of 9 , May 1, 2004
                • 0 Attachment
                  > 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 8 of 9 , May 2, 2004
                  • 0 Attachment
                    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 9 of 9 , May 3, 2004
                    • 0 Attachment
                      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.