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

Re: [XP] How do you eat an elephant?

Expand Messages
  • yahoogroups@jhrothjr.com
    ... ... One bite at a time. ... That s too many developers for one team. You need to split the
    Message 1 of 3 , May 1, 2004
    • 0 Attachment
      > From: "Orhan Kalayci"
      <orhan.kalayci.at.nitelik.net@...>
      > Sent: Saturday, May 01, 2004 8:24 AM
      > Subject: [XP] How do you eat an elephant?

      One bite at a time.

      > Dear all,

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

      That's too many developers for one team. You need to
      split the project into two or more subsystems, so that you
      have between three and ten (or so) developers on each one.

      > Requirements are already documented largely in paper.
      > The schedule is very tight.

      What is your experiance to date on the adequacy
      of "complete" requirements? In other words, how
      much change do you expect, based on past experiance,
      in the requirements as the project progresses. That isn't
      just "major" change that's covered with a formal change
      request, but minor clarifications of incomplete, conflicting
      or imprecise requirements?

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

      I'm not sure what you're saying. Are you saying that there
      is some pressure to start coding before design is complete,
      or there is some pressure to *not* start coding before design
      is complete?

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

      That's backwards. XP says that it's more risky to do a complete
      design up front. Specifically, you have:

      1. Obsolescence risk when the requirements change.
      2. Quality risk because the design has not been validated.
      3. Excessive cost of communication if the developers need
      to expand on the design.

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

      I think you mean incremental design. Incremental design
      only works if you do ruthless refactoring (and restructuring
      when necessary). Ruthless refactoring and restructuring only
      work when you have a complete suite of programmer and
      customer tests against which to verify the changes.

      In other words, you need to do all of the core XP
      software engineering practices in order to make incremental
      design work.

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

      One way of looking at XP is to see it as a design process where
      the design is immediately reduced to code to validate it. In general,
      it's not going to be possible to practice incremental design without
      refactoring. Whether you will be able to avoid larger restructurings
      depends on how good the original design concept is. In other words,
      if you don't learn a lot during the project, you'll probably get away
      without major restructurings.

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

      Design in XP requires that you do the best you possibly can.
      That is, simple design is not simplistic design. Just about everything
      you've ever learned about "good" design needs to be applied, with
      one exception. That is, of course, that you should avoid designing
      in complicated mechanisms "just in case" they're going to be needed.

      > Thank you in advance,
      > Orhan Kalayci

      You're welcome.
      John Roth
    • Keith Ray
      ... This says to me we don t have slack in the schedule to rethink the design after we ve learned what doesn t work. That s bad. -- C. Keith Ray
      Message 2 of 3 , May 1, 2004
      • 0 Attachment
        >> 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.)

        This says to me "we don't have slack in the schedule to rethink the
        design after we've learned what doesn't work." That's bad.

        --
        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>
      • J. B. Rainsberger
        ... Keith understates it considerably. If your project is scheduled in such a way that you have to get each thing right the first time, then I strongly suggest
        Message 3 of 3 , May 1, 2004
        • 0 Attachment
          Keith Ray wrote:

          >>>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.)
          >
          > This says to me "we don't have slack in the schedule to rethink the
          > design after we've learned what doesn't work." That's bad.

          Keith understates it considerably.

          If your project is scheduled in such a way that you have to get each
          thing right the first time, then I strongly suggest you run away,
          screaming. I would. You're doomed.

          This is a case where prioritization is the only thing to save you, short
          of a miracle. Your stakeholders must split the features in half: the
          half they need and the half they want. If they can't be happy getting
          half the features, then you can't make them happy at all. Save your
          sanity and don't try.

          I know this is harsh, but in that situation I have told a client, "Look,
          if you can find someone else to do all this stuff in the time you've
          specified, then hire them and not me. I can do X in that time, so if
          that's not good enough for you, then neither am I." All of a sudden, the
          conversation changed: "Well, we can do without 1, 2 and 3...." and
          within two hours we had a workable schedule and I had work to do. It
          went well.
          --
          J. B. Rainsberger,
          Diaspar Software Services
          http://www.diasparsoftware.com :: +1 416 791-8603
          Let's write software that people understand
        Your message has been successfully submitted and would be delivered to recipients shortly.