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

YAGNI

Expand Messages
  • Stephan Schmidt
    Just one thought, YAGNI is like lazy initialization, just initialize your code when you need it :-) -stephan
    Message 1 of 19 , Aug 4, 2000
    • 0 Attachment
      Just one thought,

      YAGNI is like lazy initialization, just initialize your code when you need
      it :-)

      -stephan
    • Michael C. Feathers
      Don, The big question that I have is: what are you doing with these preferences? Are they things that you decode and then use to set your state? Here is
      Message 2 of 19 , Aug 4, 2000
      • 0 Attachment
        Don,

        The big question that I have is: what are you doing
        with these preferences? Are they things that you
        decode and then use to set your state?

        Here is another option: make a
        preference accept an interface and
        have the preference set your state.

        In the calling code:

        UserPreferences.getPreference ("BackgroundColor").configure (this);

        or more concisely:

        UserPreferences.configure (this, "BackgroundColor");

        From one point of view, this is not simple. From
        another it is. It obeys the "Tell, Don't Ask"
        principle that Dave Thomas and Andrew Hunt
        mention on the Pragmatic Programmer website.

        Upside: you do not have to fret about the
        return type of getPreference. It can just be
        Preference and it'll never change. Also,
        you avoid encoding, pushing more to the
        level of protocol rather than data.

        Downside: it forces visitor-like mechanations
        on the brain.


        Comments?

        Michael

        ----- Original Message -----
        From: Donald F. McLean <dmclean@...>
        To: XP Mailing List <extremeprogramming@egroups.com>
        Sent: Friday, August 04, 2000 11:30 AM
        Subject: [XP] When Is Simpler More Complicated?


        > I'm working on an application that has a number of
        > user setable preferences for colors and such and I'm
        > wondering what people think about various approaches
        > to implementing this. Our application has one (which
        > one I won't say) and I can think of two others.
        >
        > Feel free to suggest alternatives.
        >
        > Obviously, implementation three gets bigger every
        > time a new preference is added. Implementation two
        > only gets bigger when a preference with a new type
        > is added. Implementation one is a little clumsier.
        >
        > All implementations use a singleton object for the
        > UserPreferences class.
        > ------------------------------------------------------
        > Implementation One
        > ------------------------------------------------------
        > public class UserPreferences
        > {
        > Hashtable preferences;
        >
        > public Object getPreference (String preferenceName)
        > {
        > return (preferences.find (preferenceName));
        > }
        > }
        >
        > class SomeUserObject
        > {
        > void someFunction
        > {
        > ObjectType preferenceValue =
        > (ObjectType)UserPreferences.getPreference (prefName);
        > }
        > }
        > ------------------------------------------------------------
        > Implementation Two
        > ------------------------------------------------------------
        > public class UserPreferences
        > {
        > Hashtable preferences;
        >
        > public SomeType getSomeTypePreference (String preferenceName)
        > {
        > Object temp = preferences.find (preferenceName);
        > if (temp instanceOf SomeType)
        > {
        > return ((SomeType)temp);
        > }
        > else
        > {
        > throw exception;
        > }
        > }
        > }
        >
        > class SomeUserObject
        > {
        > void someFunction
        > {
        > ObjectType preferenceValue =
        > UserPreferences.getSomeTypePreference (prefName);
        > }
        > }
        > ----------------------------------------------------------------
        > Implementation Three
        > ----------------------------------------------------------------
        > public class UserPreferences
        > {
        > SomeType somePreference;
        >
        > public SomeType getSomePreference ()
        > {
        > return (somePreference);
        > }
        > }
        >
        > class SomeUserObject
        > {
        > void someFunction
        > {
        > SomeType preferenceValue = UserPreferences.getSomePreference();
        > }
        > }
        > --

        ---------------------------------------------------
        Michael Feathers mfeathers@...
        Object Mentor Inc. www.objectmentor.com
        Training/Mentoring/Development
        -----------------------------------------------------
        "You think you know when you can learn, are more sure when
        you can write, even more when you can teach, but certain when
        you can program. " - Alan Perlis
      • Georg Tuparev
        One of the best ways to cope with user preferences is Apple s NSUserDefaults class. Here a pointer to it:
        Message 3 of 19 , Aug 9, 2000
        • 0 Attachment
          One of the best ways to cope with user preferences is Apple's
          NSUserDefaults class. Here a pointer to it:

          http://developer.apple.com/techpubs/macosx/System/Library/Frameworks/Foundation.framework/Versions/C/Resources/English.lproj/Documentation/Reference/Java/Classes/NSUserDefaults.html

          I hope this will give you some inspirations...

          gt


          > I'm working on an application that has a number of
          > user setable preferences for colors and such and I'm
          > wondering what people think about various approaches
          > to implementing this. Our application has one (which
          > one I won't say) and I can think of two others.
          >


          --
          Georg Tuparev <gtupar@...>
          COSS ObjectZoo Ltd.
          Titiaanstraat 13 3 Cathles Road
          1077 RC Amsterdam, The Netherlands London SW12 9LE, UK
          Mobile: +31-655-798196 Fax: +31-20-524-1254
        • Phlip
          ... YAGNI does not mean you pretend you know nothing about the project except the past and current UserStories. It means you don t waste gobs of time investing
          Message 4 of 19 , Apr 30 12:14 PM
          • 0 Attachment
            Proclaimed Brian Christopher Robinson from the mountaintops:

            > A question about YAGNI. Let's say I'm creating a class for my program.
            > I have two possible ways of doing it that AFAICT are equally good in
            > terms of the story I'm working on now. However, I know that one way
            > will be better for some future story I'm not working on yet. Is it
            > wrong to work with that future knowledge?

            YAGNI does not mean you pretend you know nothing about the project except
            the past and current UserStories.

            It means you don't waste gobs of time investing in speculative code. No
            gold-plating, or adding "flexibility". The correct way to add flexibility
            is to let further UserStories flex the design!

            If you say the two ways are equally "good", let's take that to mean they
            will be around the same line count. Or maybe even the predictive version
            is 5% longer. Go ahead and code it. This is not the same as the Bad Old
            Days, when folks would hole up and code, hand over fist, entire packages
            entirely on speculation.

            http://c2.com/cgi/wiki?JobSecurity

            --
            Phlip phlip_cpp@...
            ============== http://phlip.webjump.com ==============
            This signature was automatically generated with
            Signify v1.06. For this and other cool products,
            check out http://www.debian.org/
          • Phil Goodwin
            ... The impulse to kill two birds with one stone is a distraction that is best avoided. If you are thinking about two different stories while you are writing
            Message 5 of 19 , Apr 30 12:36 PM
            • 0 Attachment
              At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
              >A question about YAGNI. Let's say I'm creating a class for my program. I
              >have two possible ways of doing it that AFAICT are equally good in terms of
              >the story I'm working on now. However, I know that one way will be better
              >for some future story I'm not working on yet. Is it wrong to work with
              >that future knowledge?

              The impulse to kill two birds with one stone is a distraction that is best avoided. If you are thinking about two different stories while you are writing code then you aren't writing the best code you can. Think about one story at a time and let the tests force you to complicate your thinking if and when that becomes necessary.


              ------------------------------------------------------------------------------------------------------------
              Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

              "If everything you try works, you aren't trying hard enough." -- Gordon Moore
            • azami@speakeasy.net
              ... program. I ... terms of ... better ... with ... Suppose you solve the problem with the informed design (the way that s better for the future story).
              Message 6 of 19 , Apr 30 12:36 PM
              • 0 Attachment
                --- In extremeprogramming@y..., Brian Christopher Robinson
                <brian@d...> wrote:
                > A question about YAGNI. Let's say I'm creating a class for my
                program. I
                > have two possible ways of doing it that AFAICT are equally good in
                terms of
                > the story I'm working on now. However, I know that one way will be
                better
                > for some future story I'm not working on yet. Is it wrong to work
                with
                > that future knowledge?

                Suppose you solve the problem with the informed design (the way that's
                better for the future story). Then, that story gets dropped. How do
                you feel about the state of the code? Is it as simple as it can
                possibly be?

                Now, suppose you solve the problem the other way. The future story
                becomes current, and you begin working on it by refactoring from the
                design you used to the design you considered. How much does this
                hurt?

                -Matthew
                azami@...
              • Ron Jeffries
                ... Is one of them simpler than the other? I always go with the simplest. But I try not to do things that would obviously work. Can you think of a specific
                Message 7 of 19 , Apr 30 12:41 PM
                • 0 Attachment
                  Responding to Brian Christopher Robinson (03:05 PM 4/30/2001 -0500):
                  >A question about YAGNI. Let's say I'm creating a class for my program. I
                  >have two possible ways of doing it that AFAICT are equally good in terms of
                  >the story I'm working on now. However, I know that one way will be better
                  >for some future story I'm not working on yet. Is it wrong to work with
                  >that future knowledge?

                  Is one of them simpler than the other? I always go with the simplest. But I
                  try not to do things that would obviously work.

                  Can you think of a specific example?



                  Ronald E Jeffries
                  http://www.XProgramming.com
                  http://www.objectmentor.com
                • Brian Christopher Robinson
                  A question about YAGNI. Let s say I m creating a class for my program. I have two possible ways of doing it that AFAICT are equally good in terms of the
                  Message 8 of 19 , Apr 30 1:05 PM
                  • 0 Attachment
                    A question about YAGNI. Let's say I'm creating a class for my program. I
                    have two possible ways of doing it that AFAICT are equally good in terms of
                    the story I'm working on now. However, I know that one way will be better
                    for some future story I'm not working on yet. Is it wrong to work with
                    that future knowledge?
                  • Ron Jeffries
                    ... Actually I try not to do things that would obviously NOT work ... ;- Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
                    Message 9 of 19 , Apr 30 1:28 PM
                    • 0 Attachment
                      Responding to Ron Jeffries (03:41 PM 4/30/2001 -0400):
                      >But I
                      >try not to do things that would obviously work.

                      Actually I try not to do things that would obviously NOT work ... ;->



                      Ronald E Jeffries
                      http://www.XProgramming.com
                      http://www.objectmentor.com
                    • Phil Goodwin
                      ... I think that it depends on how you use it. If it s deepening your understanding of your current story then it s good. If it s distracting you with
                      Message 10 of 19 , Apr 30 1:29 PM
                      • 0 Attachment
                        At 03:05 PM 4/30/01 -0500, Brian Christopher Robinson wrote:
                        >A question about YAGNI. Let's say I'm creating a class for my program. I
                        >have two possible ways of doing it that AFAICT are equally good in terms of
                        >the story I'm working on now. However, I know that one way will be better
                        >for some future story I'm not working on yet. Is it wrong to work with
                        >that future knowledge?

                        I think that it depends on how you use it. If it's deepening your understanding of your current story then it's good. If it's distracting you with considerations that aren't pertinent to your current story then it's not so good.

                        Trying to figure out which is which is a distraction itself.

                        When I'm working on a particular story I try to make sure that I focus on that story. If I find myself thinking about another story I check to see whether my thoughts are getting clearer and more focused or whether I'm starting to get distracted (this comes out as either worry or fascination). If I'm distracted I write down my thought on a card and re-focus on the current story. If I'm getting clarity I go with it.

                        The original question assumes that you are working on a pretty course grained level of design: which class to use. If you are thinking about what method to write next the problem pretty much goes away for a while. When it comes back it will be in the form of how to refactor the methods into classes that make more sense. At that point the other story you were worrying about probably won't enter into the picture. Unless of course you've started to implement it by the time this refactoring wants to happen. Thinking this way makes the original question seem less relevant: if you aren't planning your classes ahead of implementing them it doesn't make sense to ponder about how that planning should be done.

                        ------------------------------------------------------------------------------------------------------------
                        Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

                        "If everything you try works, you aren't trying hard enough." -- Gordon Moore
                      • Brian C. Robinson
                        ... Actually this is something that has almost but not quite come up a couple of times in our project. Basically, I will be thinking about something and one
                        Message 11 of 19 , Apr 30 1:58 PM
                        • 0 Attachment
                          At 02:41 PM 4/30/01, you wrote:
                          >Can you think of a specific example?

                          Actually this is something that has almost but not quite come up a couple
                          of times in our project. Basically, I will be thinking about something and
                          one of the options I am considering looks like it might be useful in the
                          future but then when I think about it some more I realize that it probably
                          won't. But it did lead me to the hypothetical situation I originally described.
                        • Phlip
                          ... What s the one thing better than OnceAndOnlyOnce? NoneAndOnlyNone. -- Phlip phlip_cpp@my-deja.com ==============
                          Message 12 of 19 , Apr 30 2:56 PM
                          • 0 Attachment
                            Proclaimed Brian Christopher Robinson from the mountaintops:

                            > A question about YAGNI. Let's say I'm creating a class for my program.
                            > I have two possible ways of doing it that AFAICT are equally good in
                            > terms of the story I'm working on now. However, I know that one way
                            > will be better for some future story I'm not working on yet. Is it
                            > wrong to work with that future knowledge?

                            What's the one thing better than OnceAndOnlyOnce?

                            NoneAndOnlyNone.

                            --
                            Phlip phlip_cpp@...
                            ============== http://phlip.webjump.com ==============
                            -- Programming without Tan Lines, LLC --
                          • Dossy
                            ... I know folks have already contributed to this, but let me add what I ve learned by reading this list -- Guesses are usually wrong. Without getting into a
                            Message 13 of 19 , Apr 30 5:51 PM
                            • 0 Attachment
                              On 2001.04.30, Brian Christopher Robinson <brian@...> wrote:
                              > A question about YAGNI. Let's say I'm creating a class for my program. I
                              > have two possible ways of doing it that AFAICT are equally good in terms of
                              > the story I'm working on now. However, I know that one way will be better
                              > for some future story I'm not working on yet. 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.

                              Without getting into a huge epistemological debate about what "know"
                              really means, make sure you _really_ know, and not just _think_ you
                              know.

                              "Future story" means "don't know" in my book, but you may hold a
                              slightly different meaning. If your meaning differs from mine,
                              just remember that the customer can rip up a "future story" at
                              any time, making it no longer a "future story" -- that's why
                              I say it really means "don't know".

                              If you DTSTTCPW given the current stories you've agreed to implement
                              this iteration, then implementing the new stories from the next
                              iteration (read: today's "future stories") shouldn't be that
                              painful. Perhaps even less painful than if you'd written your
                              code in anticipation of them ...

                              - Dossy

                              --
                              Dossy Shiobara mail: dossy@...
                              Panoptic Computer Network web: http://www.panoptic.com/
                            • 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 14 of 19 , May 1, 2001
                              • 0 Attachment
                                --- 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 15 of 19 , May 1, 2001
                                • 0 Attachment
                                  ...
                                  >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 16 of 19 , May 1, 2001
                                  • 0 Attachment
                                    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 17 of 19 , May 2, 2001
                                    • 0 Attachment
                                      --- 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 18 of 19 , May 2, 2001
                                      • 0 Attachment
                                        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 19 of 19 , May 3, 2001
                                        • 0 Attachment
                                          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.