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

Re: [XP] YAGNI

Expand Messages
  • 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 1 of 19 , Apr 30, 2001
    • 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 2 of 19 , Apr 30, 2001
      • 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 3 of 19 , Apr 30, 2001
        • 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
        • 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 4 of 19 , Apr 30, 2001
          • 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 5 of 19 , Apr 30, 2001
            • 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 6 of 19 , Apr 30, 2001
              • 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 7 of 19 , Apr 30, 2001
                • 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 8 of 19 , Apr 30, 2001
                  • 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 9 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 10 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 11 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 12 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 13 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 14 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.