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

Re: [XP] YAGNI

Expand Messages
  • ian.rae@pronexus.com
    ... Except that there are two reasons why stories don t get into the current iteration: they are lower priority OR there s not time to do them in the iteration
    Message 1 of 19 , May 1, 2001
      --- In extremeprogramming@y..., Dossy <dossy@p...> wrote:
      > On 2001.04.30, Brian Christopher Robinson <brian@d...> wrote:
      > > A question about YAGNI.
      >[..] Is it wrong to work with that future knowledge?
      >
      > I know folks have already contributed to this, but let me add what
      > I've learned by reading this list --
      >
      > Guesses are usually wrong.
      > [..]

      Except that there are two reasons why stories don't get into the
      current iteration: they are lower priority OR there's not time to
      do them in the iteration time span. XP tries to make the latter a
      case of the former by saying everything can be prioritized. This
      gets back to the issue of how many iterations it takes to deliver a
      minimal usable feature set. If the answer is greater than one, then
      one could argue that all stories up in the minimal set can be allowed
      to cast a shadow back on the design decisions in the first iteration
      (s).

      Saying this troubles me because YAGNI works so well from a coding
      point of view. Perhaps it is because version-1.0-shrink-wrap-
      software has no customer. Or at least only customers who will
      pay money AFTER the software is developed, and expect a fair whack
      of functionality (who would buy a car that only had first gear!).
      I suspect this is more a problem with the way software is marketed.
      SGI used to always find pilot customers who could assist in product
      definition and early trials..

      --Ian
    • Kenneth Tyler
      ... ..At one point Jacobson argues that all software should be developed as if it were maintenance work, that is, that there is really no such thing as a
      Message 2 of 19 , May 1, 2001
        ...
        >Saying this troubles me because YAGNI works so well from a coding
        >point of view. Perhaps it is because version-1.0-shrink-wrap-
        >software has no customer. Or at least only customers who will
        >pay money AFTER the software is developed, and expect a fair whack
        >of functionality (who would buy a car that only had first gear!).
        ..At one point Jacobson argues that all software should be developed as if
        it were maintenance work, that is, that there is really no such thing as a
        completely "new" system. If you think that all software has in reality a
        series of "customers" only some of which are actually coming up with money
        to "buy" it, then you have at least all the other "customers" who are hidden
        behind the "purchasers". The company that makes the software has certain
        "features" that must be in it. The programmers who have to extend and
        maintain the software have certain "features" that must be in it. The
        software that this software must collaborate with requires certain
        "features" that must be in it......a last point is that it should be
        possible to do business in somewhat the same way xp does programming. That
        is, don't build software until you have a customer asking for it. This might
        involve a little creative manuvering but why wouldn't it be possible. If
        there will be customers after the software is released, find some of them
        before it is released and pay them to play the customer role.

        Kenneth Tyler www.tinyxp.com berkeley, ca
      • Dossy
        ... The XP answer is one iteration, the very first. Usable and valuable may be two different feature sets, of course. At the end of each and every
        Message 3 of 19 , May 1, 2001
          On 2001.05.01, ian.rae@... <ian.rae@...> wrote:
          > Except that there are two reasons why stories don't get into the
          > current iteration: they are lower priority OR there's not time to
          > do them in the iteration time span. XP tries to make the latter a
          > case of the former by saying everything can be prioritized. This
          > gets back to the issue of how many iterations it takes to deliver a
          > minimal usable feature set.

          The XP answer is "one iteration, the very first." Usable and valuable
          may be two different feature sets, of course. At the end of each and
          every iteration, the XP team must deliver a "usable" system. All
          tests passing 100%, in other words. Of course, the number of features
          implemented in the first (or first few) iterations may not be "enough"
          for the customer to find sufficient value in the system, but it must
          certainly be usable and should constantly increase in value as time
          elapses.

          (Of course, I'm just picking nits out of your semantics, here.)

          However, the clear distinction between a "usable system" and
          "valuable system" are important, IMHO. Many customers are delivered
          neither a usable system nor a valuable system -- XP at least promises
          and I'd dare to say, guarantees, a usable system. In my eyes,
          that puts XP at least ahead of a lot of projects out there ...


          > If the answer is greater than one, then
          > one could argue that all stories up in the minimal set can be allowed
          > to cast a shadow back on the design decisions in the first iteration
          > (s).
          >
          > Saying this troubles me because YAGNI works so well from a coding
          > point of view.

          And DTSTTCPW is the equialent with regard to design. Lets do
          the analogy: YAGNI is to Programming as DTSTTCPW is to Designing.

          > Perhaps it is because version-1.0-shrink-wrap-
          > software has no customer. Or at least only customers who will
          > pay money AFTER the software is developed, and expect a fair whack
          > of functionality [...]

          Remember, there is a difference between what you release to your
          Business Customer at the end of every iteration, and what you
          release to the Public. It may not be until the end of Iteration 5
          that the System you deliver to your Business Customer is enough
          to shrinkwrap and deliver to the End Users or the Public as
          Version 1.0, but XP doesn't care about that. That's a Business
          decision left up to your Business Customer.

          > [...] (who would buy a car that only had first gear!).

          If I knew that every 2-3 weeks I could bring the car back to the
          manufacturer to have an additional gear, a car stereo, perhaps some
          floor mats installed -- I probably would, if the initial car
          with a frame, four tires, engine and first gear cost me 1/200th
          the cost of the entire vehicle. I would pay 1/200th the car cost
          every 2-3 weeks as well, until the entire car was fully assembled.
          If I could prioritize what parts got manufacturered and installed
          as time went on, I'd be really happy. I might even be inclined
          to stop going back (and stop paying) before things like the pesky
          seat belts and airbags and car horn got installed -- hopefully,
          before reaching 1/3rd of the total cost.

          But alas, Real Life normally isn't as good as Software Development.


          - Dossy

          --
          Dossy Shiobara mail: dossy@...
          Panoptic Computer Network web: http://www.panoptic.com/
        • ian.rae@pronexus.com
          ... a ... a ... Usable: performs useful actions for an ordinary user. ... valuable may be two different feature sets, of course. At the end of each and every
          Message 4 of 19 , May 2, 2001
            --- In extremeprogramming@y..., Dossy <dossy@p...> wrote:
            > On 2001.05.01, ian.rae@p... <ian.rae@p...> wrote:
            > > Except that there are two reasons why stories don't get into the
            > > current iteration: they are lower priority OR there's not time to
            > > do them in the iteration time span. XP tries to make the latter
            a
            > > case of the former by saying everything can be prioritized. This
            > > gets back to the issue of how many iterations it takes to deliver
            a
            > > minimal usable feature set.

            Usable: performs useful actions for an ordinary user.

            >
            > The XP answer is "one iteration, the very first." Usable and
            valuable may be two different feature sets, of course. At the end of
            each and every iteration, the XP team must deliver a "usable"
            system. All tests passing 100%, in other words.

            I would rather put it that XP teams must deliver an "installable
            and runnable" system. Whether it's usable is a customer decision.
            Eg. An (iteration 1) CAD system that can only draw rectangles on the
            screen is probably not usable in any ordinary sense of the word.

            >[..]
            > > [...] (who would buy a car that only had first gear!).
            >
            > If I knew that every 2-3 weeks I could bring the car back to the
            > manufacturer to have an additional gear, a car stereo, perhaps some
            > floor mats installed -- I probably would, if the initial car
            > with a frame, four tires, engine and first gear cost me 1/200th
            > the cost of the entire vehicle. I would pay 1/200th the car cost
            > every 2-3 weeks as well, until the entire car was fully assembled.
            > If I could prioritize what parts got manufacturered and installed
            > as time went on, I'd be really happy. I might even be inclined
            > to stop going back (and stop paying) before things like the pesky
            > seat belts and airbags and car horn got installed -- hopefully,
            > before reaching 1/3rd of the total cost.

            ..and all those annoying buzzers! Alas micropayment schemes have
            generally failed. People find it too much bother. Clay Shirky has
            an interesting article on this

            http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.html

            --Ian
          • Dossy
            ... Imagine a payroll system. The system delivered at the end of the first iteration may be only able to pay ten people of a payroll of ten thousand
            Message 5 of 19 , May 2, 2001
              On 2001.05.02, ian.rae@... <ian.rae@...> wrote:
              > I would rather put it that XP teams must deliver an "installable
              > and runnable" system. Whether it's usable is a customer decision.
              > Eg. An (iteration 1) CAD system that can only draw rectangles on the
              > screen is probably not usable in any ordinary sense of the word.

              Imagine a payroll system. The system delivered at the end of
              the first iteration may be only able to pay ten people of a
              payroll of ten thousand employees, which may not be _valuable_
              but the system is still _usable_. You can pay 10 more people
              than you could before the system was delivered. And, presumably,
              at the end of the next iteration, you should be able to pay
              at least 11 or more people.

              One of the tasks of a team implementing XP is to convince the
              business customer that any usable system has value, and that
              the perceived required amount of value before the system is
              valuable (enough) is FAR less than what they actually believe.

              > Alas micropayment schemes have generally failed. People find it too
              > much bother.

              Generalizations are generally wrong. Most of the time. *smirk*

              Do you subscribe to a newspaper? Or a magazine? While they're not
              "micro" in the strict definition of the prefix "micro" being a
              millionth of a larger sum, subscriptions are a form of installment
              payment for a larger body of content which you believe you will
              receive over time.

              The reason why many business models that revolve around the
              micropayment, subscription model, or installment plan scheme
              have failed isn't because of "too much bother" but rather because
              the supplier usually fails to deliver. Why pay for an ongoing
              service when the service isn't there? Would you pay for a
              newspaper subscription if subsequent issues contained the exact
              same content as the first few?

              But, anyway, this is getting off-topic. Thanks for entertaining
              the idea, though.

              - Dossy

              --
              Dossy Shiobara mail: dossy@...
              Panoptic Computer Network web: http://www.panoptic.com/
            • GlenB Alleman
              Responding to Dossy... The incremental delivery example of the payroll system has not been my experience with ERP systems. I ve been on the project
              Message 6 of 19 , May 3, 2001
                Responding to Dossy...

                The "incremental delivery" example of the payroll system has not been my
                experience with ERP systems. I've been on the project management and
                architecture side of two system in the past 4 years (SAP and Avalon). These
                systems tend to be large and unwieldy by their nature. Considering AR/AP as
                an example (since payroll is now an outsourced service in many companies),
                the incremental use of "two" system side by side is an unpleasant choice for
                most AR/AP departments. Paying 10 folks out of say 5,000 then incrementing
                to 10 more (this is actually a non-functional example BTW) creates lost of
                audit issues that can be avoided by "large grained" cutover strategies. The
                various strategies for replacing a systems is probably equal to the number
                of customers, so providing a "simple example" in the absence of a real
                customer is "theory," not practice.

                The "big cut over" choice is also unpleasant but for different reasons. The
                road is littered with disaster projects that have done the "big switch," the
                most recent here in Denver with the Public Schools personnel system. Hone
                grown to People Soft..ouch!!!

                The conjecture that a stakeholder would be willing to take "partial
                features" while running the system in production has not been my field
                experience. Others may have other experiences (outside the C3 project). If
                so it would be interesting to hear about them. The incremental transition of
                COTS products may be different than non-COTS products. BTW see the latest
                issue of IEEE Computer for the Top 10 Myths of COTS integration. Good
                reading for anyone thinking about the COTS domain and lightweight processes.

                This issue goes to the core of the XP incremental delivery process. "Where
                is it appropriate and where is it not appropriate" to deliver incremental
                value. This decision is not the domain of XP per se (or any other process)
                but of the customer. IF the customer sees value in this, then XP is a method
                that can deliver that value against this requirement. XP probably has the
                better story here, since all the practices are built around "iterative and
                incremental" delivery.

                Interestingly SAP has a similar "story" in their current light weight
                delivery process, so there is nothing new under the sun, since the marketing
                guys read the trades as well and anything with an "X" in it is useful.

                In the end the premise that incremental features have value is a balance
                sheet issue and is part of the IT Strategy for the stakeholder. XP is an
                enabler of the decision process in support of a strategy.

                Glen Alleman
                Niwot Ridge

                |Dossy wrote...
                |ian.rae@... <ian.rae@...> wrote:
                |> I would rather put it that XP teams must deliver an "installable
                |> and runnable" system. Whether it's usable is a customer decision.
                |> Eg. An (iteration 1) CAD system that can only draw rectangles on the
                |> screen is probably not usable in any ordinary sense of the word.
                |
                |Imagine a payroll system. The system delivered at the end of
                |the first iteration may be only able to pay ten people of a
                |payroll of ten thousand employees, which may not be _valuable_
                |but the system is still _usable_. You can pay 10 more people
                |than you could before the system was delivered. And, presumably,
                |at the end of the next iteration, you should be able to pay
                |at least 11 or more people.
                |
                |One of the tasks of a team implementing XP is to convince the
                |business customer that any usable system has value, and that
                |the perceived required amount of value before the system is
                |valuable (enough) is FAR less than what they actually believe.
                |
                [snip]
              Your message has been successfully submitted and would be delivered to recipients shortly.