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

Give simple design a chance

Expand Messages
  • Alex Pukinskis
    I ve recently started working with a small software team to help them in trying out XP to improve code quality, allow for a sustainable pace, and allow them to
    Message 1 of 15 , Jun 27, 2003
    • 0 Attachment
      I've recently started working with a small software team to help them
      in trying out XP to improve code quality, allow for a sustainable pace,
      and allow them to be more flexible in dealing with changing customer
      requirements. Today I introduced the basic concepts and 12 XP
      practices. In general, two developers were very excited about the
      concept, but the third (who owns the company) was skeptical about some
      of the practices. He had the usual concerns about pairing and TDD, but
      was also very skeptical about simple design and YAGNI.

      Basically, he said that he's been programming for years, and has on
      many circumstances thought ahead (by making something more generic than
      it needs to be for the current project) and had it pay off. I asked
      how many times such an an action hadn't been useful, and how many times
      it had actually got in the way. He thought that it had been a good
      decision to make a program more extensible than was immediately needed
      about 50% of the time.

      I pointed out that this meant it was a wash, and so he'd be better off
      saving the effort. He replied that he also feels it's worthwhile
      strategically for the company to try to make as many reusable modules
      as possible.

      For background - one of the key problems that this team suffers from is
      that although projects launch on time (they build web applications)
      they tend to drag on for quite a while after the delivery date. I
      suspect that this speculative development of "generic" modules does
      slow them down, and so contributes to the scheduling problems.

      We talked about how simple design makes future extensibility easier
      (one of the other developers really got this), and he nodded a few
      times, but he's really not convinced. I was wondering if anyone else
      had any experience getting seasoned developers to really give YAGNI a
      chance?

      One idea I had was that if a piece of generic "extensibility" is really
      a business requirement for the software company (as opposed to the
      customer) it should be turned into a story explicitly as part of the
      planning game (or perhaps in a separate meeting), scheduled, and billed
      to the software company (rather than the client who is paying for the
      project). That way, a business decision can be made about it, rather
      than an ad-hoc on the fly decision by the programmer. This enables
      them to see the real cost of the extensibility, and the impact that it
      has on project velocity.

      But I'd love to hear any other ideas for selling YAGNI to people who
      say their experience tells them they _will_ need it. I think this is
      pretty key to XP - am I wrong?

      -Alex
    • Kevin Smith
      ... I have been a developer for twenty years. I used to believe the same thing. ... Ron J is now promoting the idea that YAGNI is better _even if you re right
      Message 2 of 15 , Jun 27, 2003
      • 0 Attachment
        On Fri, 2003-06-27 at 18:54, Alex Pukinskis wrote:
        > Basically, he said that he's been programming for years, and has on
        > many circumstances thought ahead (by making something more generic than
        > it needs to be for the current project) and had it pay off.

        I have been a developer for twenty years. I used to believe the same
        thing.

        > He thought that it had been a good
        > decision to make a program more extensible than was immediately needed
        > about 50% of the time.
        >
        > I pointed out that this meant it was a wash, and so he'd be better off
        > saving the effort.

        Ron J is now promoting the idea that YAGNI is better _even if you're
        right every time_. I'm not completely on board with that, but I see
        where he's going with it, and I'm probably 90% in agreement.

        Using TDD and refactoring, I believe that you can usually develop a
        simple solution, and evolve it to the "right" (aka more complex)
        solution, about as fast as you could have created the "right" solution.
        But a) you got business value sooner with YAGNI, and b) if you are ever
        wrong, you avoid wasted effort with YAGNI.

        > He replied that he also feels it's worthwhile
        > strategically for the company to try to make as many reusable modules
        > as possible.

        There are two kinds of reuse: Speculative, and Opportunistic. I used to
        aim for the former, but no longer do so. The latter is valuable.

        Many people seem to value reuse as a goal itself. They forget that the
        REAL goal is to save time (money) developing or maintaining multiple
        solutions. Often, they try to design and code for reuse even though it
        would be far cheaper to build and maintain several independent
        solutions.

        > We talked about how simple design makes future extensibility easier
        > (one of the other developers really got this), and he nodded a few
        > times, but he's really not convinced. I was wondering if anyone else
        > had any experience getting seasoned developers to really give YAGNI a
        > chance?

        You might give the "bowling game" exercise a try. Have everyone in the
        team try it, either solo or as a pair. It really doesn't take that long,
        and the results may surprise you. It's probably best if you spend 15
        minutes as a group trying some up-front design.

        Don't peek at any of the solutions posted on the web, nor read ahead in
        the article, until after you've tried it yourself. Most people initially
        start to overengineer it by quite a wide margin.
        http://www.objectmentor.com/resources/articles/xpepisode.htm

        You can find other solutions (like mine) by searching the web.

        One caution: the requirements are vague, and you don't have a customer
        there to help guide you. I took the approach that we worked for a
        company that was writing the embedded software that would go into the
        scoring machines at the alley. So I didn't have to worry about input or
        exciting output. I just needed to be able to display the score for all
        frames up to the current one at any point in time.

        Be sure you agree on the basic requirements before you run off and do
        any coding.


        > One idea I had was that if a piece of generic "extensibility" is really
        > a business requirement for the software company (as opposed to the
        > customer) it should be turned into a story explicitly as part of the
        > planning game (or perhaps in a separate meeting), scheduled, and billed
        > to the software company (rather than the client who is paying for the
        > project).

        Sounds good to me.

        > But I'd love to hear any other ideas for selling YAGNI to people who
        > say their experience tells them they _will_ need it. I think this is
        > pretty key to XP - am I wrong?

        I agree with you. And getting the owner of your company to fully support
        XP is pretty key as well.

        Kevin
      • Ron Jeffries
        ... It may be, though it is not for a random programmer somewhere in the organization to say. And his self-assessed record, of being right half the time,
        Message 3 of 15 , Jun 28, 2003
        • 0 Attachment
          Around Friday, June 27, 2003, 9:54:48 PM, Alex Pukinskis wrote:

          > I've recently started working with a small software team to help them
          > in trying out XP to improve code quality, allow for a sustainable pace,
          > and allow them to be more flexible in dealing with changing customer
          > requirements. Today I introduced the basic concepts and 12 XP
          > practices. In general, two developers were very excited about the
          > concept, but the third (who owns the company) was skeptical about some
          > of the practices. He had the usual concerns about pairing and TDD, but
          > was also very skeptical about simple design and YAGNI.

          > Basically, he said that he's been programming for years, and has on
          > many circumstances thought ahead (by making something more generic than
          > it needs to be for the current project) and had it pay off. I asked
          > how many times such an an action hadn't been useful, and how many times
          > it had actually got in the way. He thought that it had been a good
          > decision to make a program more extensible than was immediately needed
          > about 50% of the time.

          > I pointed out that this meant it was a wash, and so he'd be better off
          > saving the effort. He replied that he also feels it's worthwhile
          > strategically for the company to try to make as many reusable modules
          > as possible.

          It may be, though it is not for a random programmer somewhere in the
          organization to say. And his self-assessed record, of being right half the
          time, doesn't justify the effort in any case.

          > For background - one of the key problems that this team suffers from is
          > that although projects launch on time (they build web applications)
          > they tend to drag on for quite a while after the delivery date. I
          > suspect that this speculative development of "generic" modules does
          > slow them down, and so contributes to the scheduling problems.

          I'm not sure what you're saying here about launching on time but dragging
          on. Please say more.

          > We talked about how simple design makes future extensibility easier
          > (one of the other developers really got this), and he nodded a few
          > times, but he's really not convinced. I was wondering if anyone else
          > had any experience getting seasoned developers to really give YAGNI a
          > chance?

          > One idea I had was that if a piece of generic "extensibility" is really
          > a business requirement for the software company (as opposed to the
          > customer) it should be turned into a story explicitly as part of the
          > planning game (or perhaps in a separate meeting), scheduled, and billed
          > to the software company (rather than the client who is paying for the
          > project). That way, a business decision can be made about it, rather
          > than an ad-hoc on the fly decision by the programmer. This enables
          > them to see the real cost of the extensibility, and the impact that it
          > has on project velocity.

          This is certainly a good way to go. And it recognizes that adding
          generality almost invariably does add cost.

          Certainly if there are two ways to do a thing, one general, and one less
          so, and the two cost the same to build, then we should do the more general
          one. However, if the more general one costs more, we are investing in the
          future. To make an investment now that will pay off only in the future, we
          must deal with at least these important issues:

          1. The investment of this time takes away from what we can accomplish
          now. The things we are working on now have (we presume) value which will
          begin to be realized as soon as they are done. Delaying their completion
          by working on something else reduces that return. Working on future
          generality and playing Doom have the same effect on current results: they
          make them worse.

          2. Investments in the future may or may not pay off. Therefore the
          possible return from that investment must be factored by the probability
          that the payoff will occur at all.

          3. Even when they do pay off, investments in the future must pay off more
          than investments now to be worth it. It doesn't make sense to put money
          in the bank at zero percent interest to get it back later. The loss of
          opportunity for effective investment of our money, or our time, must pay
          off more -- substantially more -- than its immediate use would provide.

          4. It is not enough to save on the /cost/ of implementation. The cost of
          adding the generality is delayed return on investment in the current
          project. Since the return on a proposed feature is greater than its cost,
          we cannot make up that loss of ROI just by saving that same cost later.

          > But I'd love to hear any other ideas for selling YAGNI to people who
          > say their experience tells them they _will_ need it. I think this is
          > pretty key to XP - am I wrong?

          It's a valuable technique because it keeps us focused on delivering
          perceived customer value all the time. If we put something in for the
          future, we may get a thrill from having done something cool, or general. We
          may even get a thrill in the future when our guess turns out to be valid.
          We will not, however, get as much credit from our current customer and
          current management as we would by getting done sooner what they are
          actually asking for.

          It is frankly a bad idea to work on something that is not wanted, slowing
          ourselves down for what is wanted. We give up pleasing someone today for
          the hope, often forlorn, of pleasing someone tomorrow.


          One last observation, just sketched for now. Quite often, we /add/
          generality. We /put in/ generality. That is, we do more work now, to make
          the system more general than it needs to be now.

          When is this investment worthwhile? It is not sufficient for this
          additional work to pay off at some future date, like Next Tuesday. It must
          also be true that the work to get the benefit Next Tuesday would be more
          than the work we put in now. If it is the same amount of effort to add the
          generality later as it is now, there is no savings at all.

          Think of it this way. Our current project requires us to do lots of work
          including feature 1.

          CP = LOW1 + F1.

          Our next project will also require lots of work, plus Feature 2, which is a
          generalization of Feature 1. We can either code Feature 2 from scratch, or
          use F1 (at no cost) plus an investment to generalize it, G1.

          NP = LOW2 + F2, or
          NP = LOW2 + G1

          Naturally, we will do whichever of these is less costly, and our assumption
          is that it is the second, the reuse.

          Now suppose that during our current project, we see this possibility. We
          see the possibility for generalizing, and we see that there will be the
          reuse in the future. Let's even suppose that we are right about that
          projection (though our record in reality is less than perfect.) We propose
          to do the generalization now. The results for the two projects will be

          CP = LOW1 + F1 + G1
          NP = LOW2

          Consider now the cost of both projects under both scenarios, with and
          without the early investment on G1, namely YAGNI and non-YAGNI

          YAGNI:
          CP + NP = (LOW1 + F1) + (LOW2 + G1)
          non-YAGNI:
          CP + NP = (LOW1 + F1 + G1) + (LOW2)

          The two projects cost the same amount! The first one is delayed. The second
          one delivers sooner relative to its start date, but its start date is
          delayed by exactly the time saved. The two projects use the same resources,
          finish on the same date, with the delivery of the first one delayed.

          Cost is the same, return is lower. Bad idea.


          Now then. We might say "but it will cost more to put it in later". If it
          will cost more, then we need more complex equations above, considering how
          much we change. But will it cost more later? I would like to see why. Will
          it not be the same code later as it is now? Will we not be smarter then
          than we are now? There is no evidence that it will cost more in general,
          and if anyone has one, we should look at an example where higher cost
          later, for the same capability, could happen at all, to see what we can
          learn.


          For non-YAGNI to pay off we need:

          1. To be right about our prediction;

          2. For our added generality to cost more later than it does now;

          3. For the deferred return of our current project to be paid back by the
          savings on new project -- which generally cannot happen, since return on
          investment of a feature exceeds its cost, or we wouldn't do it at all.

          It's this last one that is the clincher. Even if we guess right and
          completely get back the time we spend generalizing the current project, the
          real loss is on the value side of the equation, not the cost side. And the
          value is always greater than the cost, or we would not be doing the
          project.

          Hmm?

          Ron Jeffries
          www.XProgramming.com
          The central "e" in "Jeffries" is silent ... and invisible.
          Don't you wish he was?
        • Jeff Grigg
          ... Here s an alternate perspective: Using conventional development techniques (not XP), it makes all the sense in the world to develop a more general solution
          Message 4 of 15 , Jun 28, 2003
          • 0 Attachment
            --- Alex Pukinskis <alex@s...> wrote:
            > [...] the third (who owns the company) was skeptical about
            > some of the practices. [...] very skeptical about simple
            > design and YAGNI.

            Here's an alternate perspective:
            Using conventional development techniques (not XP), it makes all the
            sense in the world to develop a more general solution up front,
            instead of developing a simplistic solution and then upgrading it
            later. Software is difficult to change because it is difficult to
            test. Any change to the "simplistic" solution, making it more
            general and reusable, risks breaking any and all programs that use
            it, so they'd all have to be thoroughly retested. This will be
            expensive and time consuming, and highly likely to miss any errors
            that may sneak in.

            BUT
            Things don't have to be like that.

            With Test Driven Development, you can upgrade the design of any
            component later with very high confidence that you won't break
            anything. Rerunning the old tests is easy: It is literally
            done "with the press of a button."




            (I think our mathematical arguments based on deferred costs and
            benefits fall on deaf ears because we fail to explain how people's
            old behaviors really did make sense -- given the environment they
            were in and the techniques they were using. TDD doesn't change the
            value of money over time. TDD dramatically changes the costs of the
            options.)
          • Ron Jeffries
            ... Very interesting suggestion. It seems that when folks argue against YAGNI-style thinking, however, they rarely raise the issues you raise here. It could be
            Message 5 of 15 , Jun 28, 2003
            • 0 Attachment
              On Saturday, June 28, 2003, at 10:04:56 AM, Jeff Grigg wrote:

              > --- Alex Pukinskis <alex@s...> wrote:
              >> [...] the third (who owns the company) was skeptical about
              >> some of the practices. [...] very skeptical about simple
              >> design and YAGNI.

              > Here's an alternate perspective:
              > Using conventional development techniques (not XP), it makes all the
              > sense in the world to develop a more general solution up front,
              > instead of developing a simplistic solution and then upgrading it
              > later. Software is difficult to change because it is difficult to
              > test. Any change to the "simplistic" solution, making it more
              > general and reusable, risks breaking any and all programs that use
              > it, so they'd all have to be thoroughly retested. This will be
              > expensive and time consuming, and highly likely to miss any errors
              > that may sneak in.

              > BUT
              > Things don't have to be like that.

              > With Test Driven Development, you can upgrade the design of any
              > component later with very high confidence that you won't break
              > anything. Rerunning the old tests is easy: It is literally
              > done "with the press of a button."




              > (I think our mathematical arguments based on deferred costs and
              > benefits fall on deaf ears because we fail to explain how people's
              > old behaviors really did make sense -- given the environment they
              > were in and the techniques they were using. TDD doesn't change the
              > value of money over time. TDD dramatically changes the costs of the
              > options.)

              Very interesting suggestion. It seems that when folks argue against
              YAGNI-style thinking, however, they rarely raise the issues you raise here.
              It could be that those fears are so deeply ingrained that they "go without
              saying".

              Fascinating thought ...

              Ron Jeffries
              www.XProgramming.com
              If names and real items do not correspond with each other, there will be fighting.
              -- Jing Fa
            • Kevin Smith
              ... Somewhere in there, I would also mention that a non-YAGNI solution carries around extra complexity costs. Working around the extra complexity between point
              Message 6 of 15 , Jun 28, 2003
              • 0 Attachment
                On Sat, 2003-06-28 at 05:48, Ron Jeffries wrote:
                > For non-YAGNI to pay off we need:
                >
                > 1. To be right about our prediction;
                >
                > 2. For our added generality to cost more later than it does now;
                >
                > 3. For the deferred return of our current project to be paid back by the
                > savings on new project -- which generally cannot happen, since return on
                > investment of a feature exceeds its cost, or we wouldn't do it at all.
                >

                Somewhere in there, I would also mention that a non-YAGNI solution
                carries around extra complexity costs. Working around the extra
                complexity between point A (when it was added non-YAGNI) and point B
                (when it would have been added in a YAGNI world) increases the cost of
                the non-YAGNI approach.

                Sometimes that cost is near zero, and can be safely ignored. Other
                times, the cost can be enormous. For example, putting in a relational
                database on day one instead of starting out with flat files will often
                make every story substantially more difficult to implement and refactor.

                Kevin
              • William Pietri
                ... I ve had some success with explanations along the line Jeff is thinking. If people are used to working without unit tests and without automated refactoring
                Message 7 of 15 , Jun 28, 2003
                • 0 Attachment
                  On Sat, 2003-06-28 at 07:56, Ron Jeffries wrote:
                  >
                  > > (I think our mathematical arguments based on deferred costs and
                  > > benefits fall on deaf ears because we fail to explain how people's
                  > > old behaviors really did make sense -- given the environment they
                  > > were in and the techniques they were using. TDD doesn't change the
                  > > value of money over time. TDD dramatically changes the costs of the
                  > > options.)
                  >
                  > Very interesting suggestion. It seems that when folks argue against
                  > YAGNI-style thinking, however, they rarely raise the issues you raise here.
                  > It could be that those fears are so deeply ingrained that they "go without
                  > saying".

                  I've had some success with explanations along the line Jeff is thinking.
                  If people are used to working without unit tests and without automated
                  refactoring tools, then spending more time planning for reuse makes a
                  lot of sense, because the cost of changing something written is
                  exponentially higher. Even if they start out without that bias, a smart
                  programmer will learn from the pain they experience every time they try
                  to rejigger a core object.

                  Explaining it in those terms won't actually convince people, but once
                  you've got them to admit that something new might be going on, then it's
                  much easier to get them to suspend judgment for the duration of an
                  experiment.

                  William



                  --
                  brains for sale: http://scissor.com/
                • Alex Pukinskis
                  ... They tend to launch projects on schedule (so that the customer is using the project and happy) but they usually don t finish all of the contracted required
                  Message 8 of 15 , Jun 28, 2003
                  • 0 Attachment
                    On Saturday, June 28, 2003, at 06:48 AM, Ron Jeffries wrote:

                    >> For background - one of the key problems that this team suffers from
                    >> is
                    >> that although projects launch on time (they build web applications)
                    >> they tend to drag on for quite a while after the delivery date. I
                    >> suspect that this speculative development of "generic" modules does
                    >> slow them down, and so contributes to the scheduling problems.
                    >
                    > I'm not sure what you're saying here about launching on time but
                    > dragging
                    > on. Please say more.

                    They tend to launch projects on schedule (so that the customer is using
                    the project and happy) but they usually don't finish all of the
                    contracted required features until some time later. They have not been
                    doing iterative development, so time spent after the completion date is
                    "unexpected", and they have to eat the cost of extra development effort
                    after their "launch".

                    There are a variety of reasons this happens:
                    - Poor scheduling - they don't know their velocity and so don't factor
                    it into their scheduling; they just work with estimates as they are,
                    and end up with far more work than can be completed in the given time
                    frame.
                    - speculative development of non-required features.
                    - developers are spread thin
                    - when a client asks for additional features, they usually don't ask
                    for a corresponding change in delivery date - rather, they just pile
                    them in.
                    - a historic willingness to accept overtime as inevitable.

                    -Alex
                  • Bill Wake
                    ... wrote: [My rephrasing is in brackets - Bill] ... return] ... Kevin Smith brought up what I ll phrase as 5. Features aren t necessarily
                    Message 9 of 15 , Jun 29, 2003
                    • 0 Attachment
                      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                      <ronjeffries@a...> wrote:

                      [My rephrasing is in brackets - Bill]
                      > 1. [Time not on the highest value thing delays the highest
                      return]
                      > 2. Investments in the future may or may not pay off.
                      > Therefore the possible return from that investment must be
                      > factored by the probability that the payoff will occur at all.

                      > 3. [...] investments in the future must pay off more
                      > than investments now to be worth it.

                      > 4. [...] Since the return on a proposed feature is greater
                      > than its cost, we cannot make up that loss of ROI just by
                      >saving that same cost later.

                      Kevin Smith brought up what I'll phrase as
                      5. Features aren't necessarily independent: some generalizations now
                      can make other decisions more expensive.

                      And I'll add a relative of #2:
                      6. Guessing wrong is not necessarily a wash: if you generalize
                      wrong, you may make the later change even more expensive than it
                      would have been. (So, you may have to rip out the generalized but
                      wrong solution, returning to the simple design, and then generalize
                      it in the way "reality" requires.)

                      --Bill Wake William.Wake@... www.xp123.com
                    • Steve Berczuk
                      ... Another factor that people who distrust YAGNI is fear that once code is in the system it will /never/ go away. XP(-ish) development works to avoid this;
                      Message 10 of 15 , Jul 1, 2003
                      • 0 Attachment
                        Bill Wake wrote:

                        > Kevin Smith brought up what I'll phrase as
                        > 5. Features aren't necessarily independent: some generalizations now
                        > can make other decisions more expensive.
                        >
                        > And I'll add a relative of #2:
                        > 6. Guessing wrong is not necessarily a wash: if you generalize
                        > wrong, you may make the later change even more expensive than it
                        > would have been. (So, you may have to rip out the generalized but
                        > wrong solution, returning to the simple design, and then generalize
                        > it in the way "reality" requires.)

                        Another factor that people who distrust YAGNI is fear that once code is
                        in the system it will /never/ go away. XP(-ish) development works to
                        avoid this; you're always refactoring and verifying functionality with
                        tests. If this is the place a person is coming from, its easy to see why
                        a 'more general' solution seems like a safer bet. Of course, the problem
                        isn't lack of generality, it's lack of ability to keep the code base
                        'alive.'

                        Maybe the trick is to convice a non-believer in YAGNI that code will
                        change over time when needed?

                        -Steve



                        --
                        Steve Berczuk | steve@... | http://www.berczuk.com
                        SCM Patterns: Effective Teamwork, Practical Integration
                        www.scmpatterns.com
                      • Jeff Grigg
                        ... Old code never dies. It never goes away. Revoking existing functionality can be a remarkably difficult and dangerous thing to do: It can be somewhere
                        Message 11 of 15 , Jul 1, 2003
                        • 0 Attachment
                          > Bill Wake wrote:
                          >> 6. Guessing wrong is not necessarily a wash: if you
                          >> generalize wrong, you may make the later change even
                          >> more expensive than it would have been. (So, you may
                          >> have to rip out the generalized but wrong solution,
                          >> returning to the simple design, and then generalize
                          >> it in the way "reality" requires.)

                          --- Steve Berczuk <berczuk@a...> wrote:
                          > Another factor that people who distrust YAGNI is fear
                          > that once code is in the system it will /never/ go away.
                          > [...] If this is the place a person is coming from, its
                          > easy to see why a 'more general' solution seems like a
                          > safer bet. Of course, the problem isn't lack of generality,
                          > it's lack of ability to keep the code base 'alive.'
                          >
                          > Maybe the trick is to convice a non-believer in YAGNI that
                          > code will change over time when needed?

                          Old code never dies. It never goes away. Revoking existing
                          functionality can be a remarkably difficult and dangerous thing to
                          do: It can be somewhere between "difficult" and "impossible" to
                          determine if someone has come to rely on the "unnecessary" extra
                          functionality or generality. This means that once you put
                          inappropriate generality in, you may never be able to take it out.
                          Your only choice then is to add generality on top of generality,
                          multiplying the complexity.

                          So premature generality can be a remarkably *unsafe* bet!
                        • Curtis Cooley
                          ... If I take code out and tests break it was necessary. Otherwise it was unnecessary. If I take code out and no tests break and your code breaks then write
                          Message 12 of 15 , Jul 1, 2003
                          • 0 Attachment
                            On Tue, 2003-07-01 at 12:05, Jeff Grigg wrote:
                            > > Bill Wake wrote:
                            > >> 6. Guessing wrong is not necessarily a wash: if you
                            > >> generalize wrong, you may make the later change even
                            > >> more expensive than it would have been. (So, you may
                            > >> have to rip out the generalized but wrong solution,
                            > >> returning to the simple design, and then generalize
                            > >> it in the way "reality" requires.)
                            >
                            > --- Steve Berczuk <berczuk@a...> wrote:
                            > > Another factor that people who distrust YAGNI is fear
                            > > that once code is in the system it will /never/ go away.
                            > > [...] If this is the place a person is coming from, its
                            > > easy to see why a 'more general' solution seems like a
                            > > safer bet. Of course, the problem isn't lack of generality,
                            > > it's lack of ability to keep the code base 'alive.'
                            > >
                            > > Maybe the trick is to convice a non-believer in YAGNI that
                            > > code will change over time when needed?
                            >
                            > Old code never dies. It never goes away. Revoking existing
                            > functionality can be a remarkably difficult and dangerous thing to
                            > do: It can be somewhere between "difficult" and "impossible" to
                            > determine if someone has come to rely on the "unnecessary" extra
                            > functionality or generality. This means that once you put
                            > inappropriate generality in, you may never be able to take it out.
                            > Your only choice then is to add generality on top of generality,
                            > multiplying the complexity.
                            >
                            > So premature generality can be a remarkably *unsafe* bet!

                            If I take code out and tests break it was necessary. Otherwise it was
                            unnecessary.

                            If I take code out and no tests break and your code breaks then write
                            tests next time.

                            Kent once said something like "you know your project has reached a good
                            state when you are adding functionality while reducing lines of code." I
                            don't know how you could achieve such a state unless you were removing
                            more code than your new functionality required.

                            --
                            ======================
                            Curtis R Cooley
                            RADSoft
                            Better software faster
                            curtis@...
                            ----------------------
                            Alcazar: "Leela, this must all be very confusing."
                            Leela: "A little. That's why I've decided to hurt you until you explain it."
                          • Jeff Grigg
                            ... Correct. To safely remove unnecessary generality or functionality, you must test all functionality that might have used it after making the change. But if
                            Message 13 of 15 , Jul 1, 2003
                            • 0 Attachment
                              >>> Bill Wake wrote:
                              >>>> [...] you may have to rip out the generalized but wrong
                              >>>> solution, returning to the simple design, and then
                              >>>> generalize it in the way "reality" requires.)

                              >> --- Steve Berczuk <berczuk@a...> wrote:
                              >>> Another factor that people who distrust YAGNI is fear
                              >>> that once code is in the system it will /never/ go away.
                              >>> [...] If this is the place a person is coming from, its
                              >>> easy to see why a 'more general' solution seems like a
                              >>> safer bet. [...]

                              > On Tue, 2003-07-01 at 12:05, Jeff Grigg wrote:
                              >> Old code never dies. It never goes away. Revoking existing
                              >> functionality can be a remarkably difficult and dangerous
                              >> thing to do: [...]
                              >>
                              >> So premature generality can be a remarkably *unsafe* bet!

                              --- Curtis Cooley <curtis@r...> wrote:
                              > If I take code out and tests break it was necessary. Otherwise
                              > it was unnecessary.
                              > If I take code out and no tests break and your code breaks
                              > then write tests next time.

                              Correct. To safely remove unnecessary generality or functionality,
                              you must test all functionality that might have used it after making
                              the change.

                              But if you're not using Test Driven Development (TDD),
                              then "retesting everything" quickly becomes practically impossible.
                              _ _ _

                              So we end up with a remarkable irony:

                              If you're doing TDD, then removing unwanted generality and
                              functionality is much easier and safer than if you're not.

                              But if you're *NOT* doing YAGNI, then you're probably not doing TDD,
                              so throwing a bunch of additional functionality and generality in can
                              be *VERY* risky if it may turn out that you don't need it. So
                              what "seems like a safe bet" turns out just the opposite if the
                              additional generality or functionality is not needed.
                            • Curtis Cooley
                              ... Actually, if you are doing TDD then removing unwanted generality is impossible since you can t remove what you can t find : D -- ======================
                              Message 14 of 15 , Jul 1, 2003
                              • 0 Attachment
                                On Tue, 2003-07-01 at 14:27, Jeff Grigg wrote:
                                > >>> Bill Wake wrote:
                                > >>>> [...] you may have to rip out the generalized but wrong
                                > >>>> solution, returning to the simple design, and then
                                > >>>> generalize it in the way "reality" requires.)
                                >
                                > >> --- Steve Berczuk <berczuk@a...> wrote:
                                > >>> Another factor that people who distrust YAGNI is fear
                                > >>> that once code is in the system it will /never/ go away.
                                > >>> [...] If this is the place a person is coming from, its
                                > >>> easy to see why a 'more general' solution seems like a
                                > >>> safer bet. [...]
                                >
                                > > On Tue, 2003-07-01 at 12:05, Jeff Grigg wrote:
                                > >> Old code never dies. It never goes away. Revoking existing
                                > >> functionality can be a remarkably difficult and dangerous
                                > >> thing to do: [...]
                                > >>
                                > >> So premature generality can be a remarkably *unsafe* bet!
                                >
                                > --- Curtis Cooley <curtis@r...> wrote:
                                > > If I take code out and tests break it was necessary. Otherwise
                                > > it was unnecessary.
                                > > If I take code out and no tests break and your code breaks
                                > > then write tests next time.
                                >
                                > Correct. To safely remove unnecessary generality or functionality,
                                > you must test all functionality that might have used it after making
                                > the change.
                                >
                                > But if you're not using Test Driven Development (TDD),
                                > then "retesting everything" quickly becomes practically impossible.
                                > _ _ _
                                >
                                > So we end up with a remarkable irony:
                                >
                                > If you're doing TDD, then removing unwanted generality and
                                > functionality is much easier and safer than if you're not.

                                Actually, if you are doing TDD then removing unwanted generality is
                                impossible since you can't remove what you can't find :>D

                                --
                                ======================
                                Curtis R Cooley
                                RADSoft
                                Better software faster
                                curtis@...
                                ----------------------
                                Dr. Zoidberg: "Okay, so you're nonchalant, stop rubbing our noses in it.
                              • Steve Berczuk
                                ... I agree with you, but my point was that the old code never dies can cut both ways. Sometime people think: If I implement it this way NOW, it will never
                                Message 15 of 15 , Jul 8, 2003
                                • 0 Attachment
                                  Jeff Grigg wrote:

                                  > --- Steve Berczuk <berczuk@a...> wrote:
                                  >>Maybe the trick is to convice a non-believer in YAGNI that
                                  >>code will change over time when needed?
                                  >
                                  >
                                  > Old code never dies. It never goes away. Revoking existing
                                  > functionality can be a remarkably difficult and dangerous thing to
                                  > do: It can be somewhere between "difficult" and "impossible" to
                                  > determine if someone has come to rely on the "unnecessary" extra
                                  > functionality or generality. This means that once you put
                                  > inappropriate generality in, you may never be able to take it out.
                                  > Your only choice then is to add generality on top of generality,
                                  > multiplying the complexity.
                                  >
                                  > So premature generality can be a remarkably *unsafe* bet!

                                  I agree with you, but my point was that the 'old code never dies' can
                                  cut both ways. Sometime people think: "If I implement it this way NOW,
                                  it will never change, do I should do the most general thing..."

                                  Thinking about it, it seems that YAGNI and "Old Code Never Dies" (OCND?
                                  :) ) conflict with each other...

                                  -steve


                                  --
                                  Steve Berczuk | steve@... | http://www.berczuk.com
                                  SCM Patterns: Effective Teamwork, Practical Integration
                                  www.scmpatterns.com
                                Your message has been successfully submitted and would be delivered to recipients shortly.