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

Reuse across projects

Expand Messages
  • Brandon Olivares
    Hi, As far as I understand it, XP discourages assuming something is going to be needed until you actually get to that point where it is needed. Also according
    Message 1 of 24 , Apr 9 4:03 AM
    View Source
    • 0 Attachment
      Hi,

      As far as I understand it, XP discourages assuming something is going to be
      needed until you actually get to that point where it is needed. Also
      according to my understanding, that includes abstracting code to be more
      general for reuse, until there is duplication, and then it can be
      refactored.

      So, what about reuse across projects? That'd be duplication, but not within
      the same project.

      I've put about 30 hours into a part of this project I'm working on that I
      really think could be reused, which is why I'm curious about this. Surely
      reuse across projects can save a lot of time.

      So how do you handle this, when you're working on a new project, and there's
      a part that is very similar to something in another project? How do you know
      when to abstract it for better reuse?

      Thanks,
      Brandon
    • Ron Jeffries
      Hello, Brandon. On Thursday, April 9, 2009, at 6:03:47 AM, you ... Actually, unless the projects are being done by the same team, reuse is quite difficult to
      Message 2 of 24 , Apr 9 4:20 AM
      View Source
      • 0 Attachment
        Hello, Brandon. On Thursday, April 9, 2009, at 6:03:47 AM, you
        wrote:

        > I've put about 30 hours into a part of this project I'm working on that I
        > really think could be reused, which is why I'm curious about this. Surely
        > reuse across projects can save a lot of time.

        Actually, unless the projects are being done by the same team, reuse
        is quite difficult to do effectively. The reason is that there is a
        big difference between some part of the project that O can reuse,
        and packaging that part up well enough so that others can do so.

        I have to do work to package it that I wouldn't do for myself; I
        have to document it; I have to make it more bulletproof, removing
        issues that I just work around automatically; I have to support it
        and answer questions about it; I have to train people in how to use
        it.

        If I do those things, it's expensive. If I don't, using my stuff is
        difficult for others and doesn't help them much.

        > So how do you handle this, when you're working on a new project, and there's
        > a part that is very similar to something in another project? How do you know
        > when to abstract it for better reuse?

        I build the abstractions I need. If I need it again, in a slightly
        different context, I would improve the abstraction. But unless my
        project's purpose is to build stuff for other projects, I try not to
        waste any of my time and money building for other projects.

        If I thought I had something really cool, I'd certainly go around
        making sure people knew about it. Something might come of that. But
        I try to keep in mind that whatever group my team is trying to
        build for may well not have the time, money, or charter to build a
        product for some other department.


        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        But the attitude of faith is to let go, and become open to
        truth, whatever it might turn out to be. -- Alan Watts
      • Phlip
        ... When all the projects are in the same Grand Wazoo Build suite. That way you change one shared module, and they all rebuild and retest on the test server.
        Message 3 of 24 , Apr 9 5:37 AM
        View Source
        • 0 Attachment
          Brandon Olivares wrote:

          > So how do you handle this, when you're working on a new project, and there's
          > a part that is very similar to something in another project? How do you know
          > when to abstract it for better reuse?

          When all the projects are in the same Grand Wazoo Build suite. That way you
          change one shared module, and they all rebuild and retest on the test server.
        • George Dinwiddie
          Hi, Brandon, ... Reuse was once touted as the new wave that would make software development much more efficient. In practice, that has not generally
          Message 4 of 24 , Apr 9 6:43 AM
          View Source
          • 0 Attachment
            Hi, Brandon,

            Brandon Olivares wrote:
            > So how do you handle this, when you're working on a new project, and there's
            > a part that is very similar to something in another project? How do you know
            > when to abstract it for better reuse?

            Reuse was once touted as the "new wave" that would make software
            development much more efficient. In practice, that has not generally
            happened using any development approach, XP or not. The reason is that
            it's very difficult to do well.

            The traditional approach to reuse is to create frameworks that are then
            expected to be used by various teams. I've seen this a lot, and
            generally these frameworks either don't quite fit the needs of the
            project using them (requiring a LOT of extra effort), or inhibit the
            advancement of the state of the art in an organization (resulting in a
            lot of code tied to an obsolete framework). Or both, simultaneously.

            The alternative, which I've found to work fairly well, though not often,
            is to generalize at the second use. When I need some functionality that
            I know exists in a different project, I'll copy the code for that
            functionality and write my own use of it, generalizing it as I go. When
            there is time and interest, I'll back port the generalized version to
            the old project.

            The first and biggest problem is one of awareness. How do you know
            about the existence of code that solves the problem you have? It's
            fairly easy if you worked on the previous code yourself. Otherwise, it
            takes a lot of detailed communication between teams. I've seen this
            work with a small cluster of teams within a department when there's a
            good bit of cross-communication and question asking between them.

            I've thought that it /could/ work with a larger group of teams given an
            active SIG where people talk about the work they're doing and present it
            to others. Alas, when I've seen such groups be formed in a corporate
            environment, they seem to get lost in setting up formal mechanisms and
            rules and never get to the sharing part. Of course, I've seen the same
            thing happen with the "design for reuse upfront" approach; code which
            has received a lot of effort to make it reusable doesn't get reused
            because people aren't aware that it exists and suits their problem.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Jeff Langr
            Hi George, ... That s a huge challenge! I ve seen attempts to broadcast information, repositories with search capabilities, and so on, but little success. Even
            Message 5 of 24 , Apr 9 7:37 AM
            View Source
            • 0 Attachment
              Hi George,

              > The first and biggest problem is one of awareness. How do you know
              > about the existence of code that solves the problem you have?

              That's a huge challenge! I've seen attempts to broadcast information,
              repositories with search capabilities, and so on, but little success. Even
              if code is shared and broadly applicable, the likeliness that others use
              it is low. Learning how to use a shared module can be a big barrier, and
              there's also the thought that, gee, I might invest all this time in
              figuring this thing out and then find out that it has limitations
              preventing me from using it.

              But if you're pairing with someone, hey, we could use this module here
              that I know about, and hey, I'll help you figure out how to reuse it. If
              you have pairing throughout the organization, that starts to promote
              people moving around more freely between teams and thus more broadly
              sharing the knowledge.

              I have a good list of benefits of pairing; maybe I should update it to
              contain "helps facilitate reuse."

              Jeff
            • Brandon Olivares
              ... That sounds interesting. I would predict though that it would rarely get backported to the previous project, since it already works as-is? That s not
              Message 6 of 24 , Apr 9 9:06 AM
              View Source
              • 0 Attachment
                > -----Original Message-----
                > From: extremeprogramming@yahoogroups.com
                > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of George
                > Dinwiddie
                > Sent: Thursday, April 09, 2009 9:44 AM
                > To: extremeprogramming@yahoogroups.com
                > Subject: Re: [XP] Reuse across projects
                >
                >
                >
                > Hi, Brandon,
                >
                > Reuse was once touted as the "new wave" that would make software
                > development much more efficient. In practice, that has not generally
                > happened using any development approach, XP or not. The reason is that
                > it's very difficult to do well.
                >
                > The traditional approach to reuse is to create frameworks that are then
                > expected to be used by various teams. I've seen this a lot, and
                > generally these frameworks either don't quite fit the needs of the
                > project using them (requiring a LOT of extra effort), or inhibit the
                > advancement of the state of the art in an organization (resulting in a
                > lot of code tied to an obsolete framework). Or both, simultaneously.
                >
                > The alternative, which I've found to work fairly well, though not
                > often,
                > is to generalize at the second use. When I need some functionality that
                > I know exists in a different project, I'll copy the code for that
                > functionality and write my own use of it, generalizing it as I go. When
                > there is time and interest, I'll back port the generalized version to
                > the old project.

                That sounds interesting. I would predict though that it would rarely get
                backported to the previous project, since it already works as-is? That's not
                necessarily a bad thing, though.

                >
                > The first and biggest problem is one of awareness. How do you know
                > about the existence of code that solves the problem you have? It's
                > fairly easy if you worked on the previous code yourself. Otherwise, it
                > takes a lot of detailed communication between teams. I've seen this
                > work with a small cluster of teams within a department when there's a
                > good bit of cross-communication and question asking between them.
                >
                > I've thought that it /could/ work with a larger group of teams given an
                > active SIG where people talk about the work they're doing and present
                > it
                > to others. Alas, when I've seen such groups be formed in a corporate
                > environment, they seem to get lost in setting up formal mechanisms and
                > rules and never get to the sharing part. Of course, I've seen the same
                > thing happen with the "design for reuse upfront" approach; code which
                > has received a lot of effort to make it reusable doesn't get reused
                > because people aren't aware that it exists and suits their problem.

                Right now, I'm working by myself, so It's not really an issue. It's good to
                think about for the future, though.

                Brandon
              • George Dinwiddie
                ... If there s benefit to ongoing work on the original project, then the chances are pretty good. The generalization process often makes the code easier to
                Message 7 of 24 , Apr 9 12:00 PM
                View Source
                • 0 Attachment
                  Brandon Olivares wrote:
                  >> The alternative, which I've found to work fairly well, though not
                  >> often,
                  >> is to generalize at the second use. When I need some functionality that
                  >> I know exists in a different project, I'll copy the code for that
                  >> functionality and write my own use of it, generalizing it as I go. When
                  >> there is time and interest, I'll back port the generalized version to
                  >> the old project.
                  >
                  > That sounds interesting. I would predict though that it would rarely get
                  > backported to the previous project, since it already works as-is? That's not
                  > necessarily a bad thing, though.

                  If there's benefit to ongoing work on the original project, then the
                  chances are pretty good. The generalization process often makes the
                  code easier to use or more robust against all conditions. Either can
                  provide the impetus to use it in the original project--if work is still
                  going on in that project.

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • timander37
                  I m glad to see that others also identify this as a very difficult thing to do. We have been struggling with this for a while and I feel that we have a decent
                  Message 8 of 24 , Apr 9 12:08 PM
                  View Source
                  • 0 Attachment
                    I'm glad to see that others also identify this as a very difficult thing to do. We have been struggling with this for a while and I feel that we have a decent handle on it, but agree that it is very challenging.

                    We extract the common pieces that can be reused into a module that can be depended upon or a service that can be pointed at. A couple of examples I can share are services for authentication/security and running credit checks, digitally archiving documents and parsing files.

                    We tell our business people "The first time you have to pay for it to be coded, the second time you have to pay for it to be reusable, the third time it's free".

                    Much of our "shared code" becomes another module (jar file) that can be included to provide the reusable functionality. Maven2 has been a very useful tool to manage our dependencies and provide plugins for reusable build components as well.

                    Tim



                    --- In extremeprogramming@yahoogroups.com, "Brandon Olivares" <programmer2188@...> wrote:
                    >
                    > Hi,
                    >
                    > As far as I understand it, XP discourages assuming something is going to be
                    > needed until you actually get to that point where it is needed. Also
                    > according to my understanding, that includes abstracting code to be more
                    > general for reuse, until there is duplication, and then it can be
                    > refactored.
                    >
                    > So, what about reuse across projects? That'd be duplication, but not within
                    > the same project.
                    >
                    > I've put about 30 hours into a part of this project I'm working on that I
                    > really think could be reused, which is why I'm curious about this. Surely
                    > reuse across projects can save a lot of time.
                    >
                    > So how do you handle this, when you're working on a new project, and there's
                    > a part that is very similar to something in another project? How do you know
                    > when to abstract it for better reuse?
                    >
                    > Thanks,
                    > Brandon
                    >
                  • Brian Marick
                    Surely someone has studied how reuse works in open source. One Ruby repository (rubyforge) has 7558 projects. I imagine the use of them follows a sharply
                    Message 9 of 24 , Apr 9 3:38 PM
                    View Source
                    • 0 Attachment
                      Surely someone has studied how reuse works in open source. One Ruby
                      repository (rubyforge) has 7558 projects. I imagine the use of them
                      follows a sharply declining power curve, but it sure looks like some
                      people have made their code reusable and others have reused it.

                      -----
                      Brian Marick, independent consultant
                      Mostly on agile methods with a testing slant
                      www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
                    • Brandon Olivares
                      ... That s exactly what I m thinking. What people are saying makes sense, but if everyone had that mindset, we wouldn t have frameworks such as Rails, nor any
                      Message 10 of 24 , Apr 9 4:10 PM
                      View Source
                      • 0 Attachment
                        > -----Original Message-----
                        > From: extremeprogramming@yahoogroups.com
                        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Brian Marick
                        > Sent: Thursday, April 09, 2009 6:39 PM
                        > To: extremeprogramming@yahoogroups.com
                        > Subject: Re: [XP] Reuse across projects
                        >
                        >
                        >
                        > Surely someone has studied how reuse works in open source. One Ruby
                        > repository (rubyforge) has 7558 projects. I imagine the use of them
                        > follows a sharply declining power curve, but it sure looks like some
                        > people have made their code reusable and others have reused it.

                        That's exactly what I'm thinking. What people are saying makes sense, but if
                        everyone had that mindset, we wouldn't have frameworks such as Rails, nor
                        any of the many gems that are out there. Even if people figured out how to
                        reuse across projects, it probably wouldn't be across individuals or
                        companies like open source generally is.

                        On the other hand, I had a problem that I was dealing with, that I was
                        looking for a gem for. I decided instead to work my way through it with BDD,
                        and came up with a solution I was happy with. Still, if this happens on the
                        next project, I don't want to have to put in as much work to get the same
                        solution.

                        Brandon
                      • Adam Sroka
                        ... There are at least two sides to this: It used to be believed, and is still believed by some, that reuse was a goal in and of itself. In fact, it is the
                        Message 11 of 24 , Apr 9 4:14 PM
                        View Source
                        • 0 Attachment
                          On Thu, Apr 9, 2009 at 3:38 PM, Brian Marick <marick@...> wrote:
                          >
                          >
                          > Surely someone has studied how reuse works in open source. One Ruby
                          > repository (rubyforge) has 7558 projects. I imagine the use of them
                          > follows a sharply declining power curve, but it sure looks like some
                          > people have made their code reusable and others have reused it.
                          >

                          There are at least two sides to this:

                          It used to be believed, and is still believed by some, that reuse was
                          a goal in and of itself. In fact, it is the purported ease of reuse
                          that is listed as one of the *primary* advantages of many programming
                          paradigms (e.g. object-orientation, functional programming,
                          components/packaging, etc.) It is likely that the reactions of George,
                          Ron, and others come from a place where they have seen this, tried it,
                          and realized that it is often if not always complete bunk.

                          It turns out that these paradigms have advantages without reuse. They
                          allow us to divide our code in ways that make it easier to understand
                          and use, that reduce duplication, and that hide complexity behind
                          various layers of abstraction.

                          It also turns out that despite these things systematic reuse is really
                          hard. Reuse is also a dubious goal, especially in business software,
                          because a lot of effort can be expended seeking it and little or no
                          business value is generated from such effort.

                          At some level reuse is essential. Otherwise we would all spend our
                          days reinventing basic algorithms in assembly. The high-level
                          languages we use and the standard libraries those languages supply are
                          examples of reuse at its best. There are other great examples of
                          reuse. Testing frameworks come to mind.

                          Web application frameworks and GUI toolkits are good examples of
                          high-level reuse. These are also examples of where we start to get
                          ourselves in trouble. I think that anyone who has been programming for
                          more than a couple years is familiar with the following two scenarios:

                          1) The framework took a little effort to learn, but in the end it
                          saved me *so* much time. There were things I would have had to do
                          myself and the framework transparently took care of them. I was able
                          to focus on the functionality that was important to my business and
                          forget about the low level details.

                          2) The framework was really complicated. It was like learning a whole
                          new language. Plus the documentation was horrible. By the time I was
                          done I felt like I could have accomplished the same thing if I just
                          wrote the whole thing from scratch. In fact, I probably could have
                          done better because I wouldn't have wasted my time trying to
                          understand things that weren't even relevant to my project.

                          From an Agile perspective what is interesting about all of this is,
                          when do I design for reuse? Conventional wisdom says that I should
                          /always/ design for reuse. In XP we say to create the simplest thing
                          that could possibly work.

                          If I design for reuse I will want to add hooks that will enable my
                          hypothetical future user to do interesting things. I will also want to
                          shore up the API so that Future User won't do anything stupid or
                          inappropriate. Both of these things tend to lead to designs that
                          aren't as simple as they could be.

                          OTOH, simple code tends to be very easy to use. Also, it is well
                          documented because of the tests. It is likely that if I wanted to use
                          something again I could come back and find it, and I could figure out
                          how it was intended to be used by looking at the tests. I could even
                          write additional tests to verify that the code would work in my new
                          scenario. If I did that, and I found that the existing code solved a
                          current problem, then I might be able to extract this code out into
                          its own project and treat it as an independent component.

                          This last part isn't exactly "design for reuse." It is more like
                          "emergent reuse" which seems to be the one sort of reuse that is
                          rarely wasteful.
                        • Brandon Olivares
                          ... This is also an interesting idea, but how would this emergent reuse work? I can see modifying that component for each project you need it to *only* fit the
                          Message 12 of 24 , Apr 9 4:34 PM
                          View Source
                          • 0 Attachment
                            > -----Original Message-----
                            > From: extremeprogramming@yahoogroups.com
                            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Sroka
                            > Sent: Thursday, April 09, 2009 7:15 PM
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: Re: [XP] Reuse across projects
                            >
                            >
                            >
                            > OTOH, simple code tends to be very easy to use. Also, it is well
                            > documented because of the tests. It is likely that if I wanted to use
                            > something again I could come back and find it, and I could figure out
                            > how it was intended to be used by looking at the tests. I could even
                            > write additional tests to verify that the code would work in my new
                            > scenario. If I did that, and I found that the existing code solved a
                            > current problem, then I might be able to extract this code out into
                            > its own project and treat it as an independent component.
                            >
                            > This last part isn't exactly "design for reuse." It is more like
                            > "emergent reuse" which seems to be the one sort of reuse that is
                            > rarely wasteful.

                            This is also an interesting idea, but how would this emergent reuse work? I
                            can see modifying that component for each project you need it to *only* fit
                            the requirements for that project, instead of modifying it in such a way
                            that it can fit with many projects without modification.

                            Brandon
                          • George Dinwiddie
                            ... Good point, Brian. And probably the best way for an organization to let others within the same organization know about a particular reusable component is
                            Message 13 of 24 , Apr 9 4:53 PM
                            View Source
                            • 0 Attachment
                              Brian Marick wrote:
                              > Surely someone has studied how reuse works in open source. One Ruby
                              > repository (rubyforge) has 7558 projects. I imagine the use of them
                              > follows a sharply declining power curve, but it sure looks like some
                              > people have made their code reusable and others have reused it.

                              Good point, Brian. And probably the best way for an organization to let
                              others within the same organization know about a particular reusable
                              component is to make it open source and freely available to the public.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            • Scott Ambler
                              Actually, reuse is incredibly easy to achieve and occurs all the time. We see this in the form of open source software, for example. We also see this in the
                              Message 14 of 24 , Apr 10 3:59 AM
                              View Source
                              • 0 Attachment
                                Actually, reuse is incredibly easy to achieve and occurs all the time. We see this in the form of open source software, for example. We also see this in the form of code libraries, "development kits" such as the JDK, and many other simlar examples. We also see mash-ups (the stuff being mashed is getting reused) too.

                                For "private reuse" to occur effectively within an organization it requires a level of maturity that is pretty rare amongst development teams, which is why I think that we often believe reuse to be hard. The point is that there's still a heck of a lot of reuse going on that we might want to take credit for.

                                -Scott
                                http://www.ibm.com/developerworks/blogs/page/ambler
                              • Ralph E. Johnson
                                ... I don t think that is conventional wisdom. Maybe in some circles. People who study software reuse distinguish between reusable software and software that
                                Message 15 of 24 , Apr 10 6:40 AM
                                View Source
                                • 0 Attachment
                                  --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:

                                  > From an Agile perspective what is interesting about all of this is,
                                  > when do I design for reuse? Conventional wisdom says that I should
                                  > /always/ design for reuse. In XP we say to create the simplest thing
                                  > that could possibly work.

                                  I don't think that is conventional wisdom. Maybe in some circles. People who study software reuse distinguish between reusable software and software that reuses. They usually talk about two kinds of programmers; those who write reusable software and those who reuse it. This implies that it is important to figure out whether software should be reusable or not.

                                  I think that people who study software reuse tend to exaggerate the difference between those who write reusable software and those who reuse it. I agree with Adam that the best way to get reusable software is to first write something that works, often three or four times. I usually tell people that if they are sick and tired of writing the same kind of code over and over then they might be ready to write a reusable version. But more often than not, people get reusable software by taking something they used on a past project and trying to reuse it, finding it wasn't reusable and refactoring it, and (after a couple of cycles of this) eventually figuring out how to make it reusable.

                                  I agree with Adam that reuse is a double-edges sword. Sometimes it works well, sometimes it doesn't. When we decide to reuse a package, we need to be ready to change our mind. The first time we use a package, we should consider it a spike both to figure out how to use the package and also whether we should use the package.

                                  -Ralph Johnson
                                • Ralph E. Johnson
                                  ... Reuse of reusable software is easy. That is what it means for software to be reusable; it is easy to reuse. On the other hand, making reusable software
                                  Message 16 of 24 , Apr 10 6:48 AM
                                  View Source
                                  • 0 Attachment
                                    --- In extremeprogramming@yahoogroups.com, "Scott Ambler" <scottwambler@...> wrote:
                                    >
                                    > Actually, reuse is incredibly easy to achieve and occurs all the time. We see this in the form of open source software, for example. We also see this in the form of code libraries, "development kits" such as the JDK, and many other simlar examples. We also see mash-ups (the stuff being mashed is getting reused) too.
                                    >

                                    Reuse of reusable software is easy. That is what it means for software to be reusable; it is easy to reuse. On the other hand, making reusable software is hard. And a lot of software is mis-labeled "reusable". And even if it is reusable, it might solve a different problem than the one you have.

                                    I agree that the XP talk against reuse is a bit inaccurate, because nearly all modern programmers reuse lots of software. But I think the purpose of this talk against reuse is to prevent programmers from worrying about reuse prematurely. A lot of people try to make software reusable when they don't have the experience for it, and when they are in the wrong business to make it worthwhile.

                                    Reuse is a means, not an end.

                                    -Ralph Johnson
                                  • Ron Jeffries
                                    Hello, Brandon. On Thursday, April 9, 2009, at 6:10:15 PM, you ... There are plenty of things that are reused. If they are easy to reuse, it is likely that
                                    Message 17 of 24 , Apr 10 7:32 AM
                                    View Source
                                    • 0 Attachment
                                      Hello, Brandon. On Thursday, April 9, 2009, at 6:10:15 PM, you
                                      wrote:

                                      > That's exactly what I'm thinking. What people are saying makes sense, but if
                                      > everyone had that mindset, we wouldn't have frameworks such as Rails, nor
                                      > any of the many gems that are out there. Even if people figured out how to
                                      > reuse across projects, it probably wouldn't be across individuals or
                                      > companies like open source generally is.

                                      There are plenty of things that are reused. If they are easy to
                                      reuse, it is likely that plenty of effort has gone into making them
                                      easy to reuse.

                                      If our mission is to build a product for our client, and we see the
                                      opportunity to make some inner part of it reusable for others, this
                                      is likely to be a lot of work. That being the case, we need to
                                      question whether our current client should pay for it. This is true
                                      whether we are doing contract work or building a commercial tax
                                      package.

                                      Things like Rails may or may not come from some internal effort but
                                      they are intentionally created as something to be used by others.
                                      There is a great deal of investment in something like that and it
                                      has to be funded one way or another, even if only by volunteer labor
                                      for the joy of it.

                                      > On the other hand, I had a problem that I was dealing with, that I was
                                      > looking for a gem for. I decided instead to work my way through it with BDD,
                                      > and came up with a solution I was happy with. Still, if this happens on the
                                      > next project, I don't want to have to put in as much work to get the same
                                      > solution.

                                      There's a very big difference between adapting something I wrote
                                      earlier for a new use by me, and adapting it for a new use by
                                      someone else. The reason, I think, is that in creating it and making
                                      it work, I have grooved all kinds of info into my brain, which the
                                      next victiXXXXX user will not have. Therefore to get someone else to
                                      use it, at least one of us has to do a lot more work. If it's me ...
                                      again someone has to pay for it. If it's the other person ...
                                      they're not going to be happy.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      The opinions expressed here /are/ necessarily those of XProgramming.com.
                                      But I might change my mind.
                                    • Adam Sroka
                                      On Fri, Apr 10, 2009 at 7:32 AM, Ron Jeffries ... Sometimes it does make business sense, though. Rails is an example where the commercial product lent itself
                                      Message 18 of 24 , Apr 10 10:13 AM
                                      View Source
                                      • 0 Attachment
                                        On Fri, Apr 10, 2009 at 7:32 AM, Ron Jeffries
                                        <ronjeffries@...> wrote:
                                        >
                                        >
                                        > Hello, Brandon. On Thursday, April 9, 2009, at 6:10:15 PM, you
                                        > wrote:
                                        >
                                        >> That's exactly what I'm thinking. What people are saying makes sense, but
                                        >> if
                                        >> everyone had that mindset, we wouldn't have frameworks such as Rails, nor
                                        >> any of the many gems that are out there. Even if people figured out how to
                                        >> reuse across projects, it probably wouldn't be across individuals or
                                        >> companies like open source generally is.
                                        >
                                        > There are plenty of things that are reused. If they are easy to
                                        > reuse, it is likely that plenty of effort has gone into making them
                                        > easy to reuse.
                                        >
                                        > If our mission is to build a product for our client, and we see the
                                        > opportunity to make some inner part of it reusable for others, this
                                        > is likely to be a lot of work. That being the case, we need to
                                        > question whether our current client should pay for it. This is true
                                        > whether we are doing contract work or building a commercial tax
                                        > package.
                                        >
                                        > Things like Rails may or may not come from some internal effort but
                                        > they are intentionally created as something to be used by others.
                                        > There is a great deal of investment in something like that and it
                                        > has to be funded one way or another, even if only by volunteer labor
                                        > for the joy of it.
                                        >

                                        Sometimes it does make business sense, though. Rails is an example
                                        where the commercial product lent itself to becoming a reusable
                                        framework and the company benefited on both ends. Opening Rails
                                        brought a lot of improvements to 37signals products, and it also
                                        brought an awareness of the company and more customers. Pretty smart,
                                        actually. They are a web design company that sells project management
                                        tools. Creating something like Rails is all kinds of good for them.

                                        There are plenty of other good examples too: Eclipse for IBM; id Tech
                                        (the Quake Engine) for id; numerous other game engines, too - though
                                        id is special because they have GPL'd theirs; etc.

                                        >> On the other hand, I had a problem that I was dealing with, that I was
                                        >> looking for a gem for. I decided instead to work my way through it with
                                        >> BDD,
                                        >> and came up with a solution I was happy with. Still, if this happens on
                                        >> the
                                        >> next project, I don't want to have to put in as much work to get the same
                                        >> solution.
                                        >
                                        > There's a very big difference between adapting something I wrote
                                        > earlier for a new use by me, and adapting it for a new use by
                                        > someone else. The reason, I think, is that in creating it and making
                                        > it work, I have grooved all kinds of info into my brain, which the
                                        > next victiXXXXX user will not have. Therefore to get someone else to
                                        > use it, at least one of us has to do a lot more work. If it's me ...
                                        > again someone has to pay for it. If it's the other person ...
                                        > they're not going to be happy.
                                        >

                                        Yes. Well put. It is important to distinguish when my team uses what
                                        my team previously used vs. someone else some other time. The latter
                                        generally requires more forethought... even for someone outside my
                                        team to be aware of it. There is a cost to that, and that cost better
                                        yield some business value (As it does in all the examples I already
                                        mentioned and numerous others I didn't think of.)

                                        Of course, that is a business decision. The business has to decide
                                        that there is value in creating something for someone else to use.
                                        Which means that we shouldn't be designing for reuse until they decide
                                        to ask us to ;-)
                                      • Steven Gordon
                                        ... The advantage of open-source is, of course, that it is unnecessary to make the framework perfect for every possible use. This reduces the cost. ... I have
                                        Message 19 of 24 , Apr 10 10:47 AM
                                        View Source
                                        • 0 Attachment
                                          On Fri, Apr 10, 2009 at 10:13 AM, Adam Sroka <adam.sroka@...> wrote:
                                          >
                                          >
                                          >
                                          > Yes. Well put. It is important to distinguish when my team uses what
                                          > my team previously used vs. someone else some other time. The latter
                                          > generally requires more forethought... even for someone outside my
                                          > team to be aware of it. There is a cost to that, and that cost better
                                          > yield some business value (As it does in all the examples I already
                                          > mentioned and numerous others I didn't think of.)

                                          The advantage of open-source is, of course, that it is unnecessary to
                                          make the framework perfect for every possible use. This reduces the
                                          cost.

                                          >
                                          > Of course, that is a business decision. The business has to decide
                                          > that there is value in creating something for someone else to use.
                                          > Which means that we shouldn't be designing for reuse until they decide
                                          > to ask us to ;-)

                                          I have seen some businesses open up their software to not only
                                          increase value for their customers, but to also:
                                          - reduce their software development and maintenance costs, and
                                          - disrupt their competitor's business models.

                                          This is especially feasible where software is an enabler rather than
                                          the core business (e.g., the core business is special purpose hardware
                                          or services).

                                          Steve
                                        • Adam Sroka
                                          ... I don t know that that is an advantage of open-source per se. Design decisions will affect the way that a framework can be (ab)used, and people will find a
                                          Message 20 of 24 , Apr 10 10:55 AM
                                          View Source
                                          • 0 Attachment
                                            On Fri, Apr 10, 2009 at 10:47 AM, Steven Gordon <sgordonphd@...> wrote:
                                            >
                                            >
                                            > On Fri, Apr 10, 2009 at 10:13 AM, Adam Sroka <adam.sroka@...> wrote:
                                            >>
                                            >>
                                            >>
                                            >> Yes. Well put. It is important to distinguish when my team uses what
                                            >> my team previously used vs. someone else some other time. The latter
                                            >> generally requires more forethought... even for someone outside my
                                            >> team to be aware of it. There is a cost to that, and that cost better
                                            >> yield some business value (As it does in all the examples I already
                                            >> mentioned and numerous others I didn't think of.)
                                            >
                                            > The advantage of open-source is, of course, that it is unnecessary to
                                            > make the framework perfect for every possible use. This reduces the
                                            > cost.
                                            >

                                            I don't know that that is an advantage of open-source per se. Design
                                            decisions will affect the way that a framework can be (ab)used, and
                                            people will find a way to use it for something it wasn't intended to
                                            do (and/or fail to use it for what they really needed to do.) These
                                            things are true almost equally for open-source and closed-source. The
                                            biggest difference in this regard is that open-source is likely to
                                            change faster and to change in ways that the original designer doesn't
                                            anticipate or necessarily desire.

                                            >>
                                            >> Of course, that is a business decision. The business has to decide
                                            >> that there is value in creating something for someone else to use.
                                            >> Which means that we shouldn't be designing for reuse until they decide
                                            >> to ask us to ;-)
                                            >
                                            > I have seen some businesses open up their software to not only
                                            > increase value for their customers, but to also:
                                            > - reduce their software development and maintenance costs, and
                                            > - disrupt their competitor's business models.
                                            >
                                            > This is especially feasible where software is an enabler rather than
                                            > the core business (e.g., the core business is special purpose hardware
                                            > or services).
                                            >

                                            Those would all be examples of business value, would they not?
                                          • Ron Jeffries
                                            ... Yes, to a first approximation. However ... I do think that much of good design just happens to be good for reuse. Small modules, not very interdependent
                                            Message 21 of 24 , Apr 10 4:51 PM
                                            View Source
                                            • 0 Attachment
                                              Hello, Adam. On Friday, April 10, 2009, at 1:13:01 PM, you wrote:

                                              > Of course, that is a business decision. The business has to decide
                                              > that there is value in creating something for someone else to use.
                                              > Which means that we shouldn't be designing for reuse until they decide
                                              > to ask us to ;-)

                                              Yes, to a first approximation. However ... I do think that much of
                                              good design just happens to be good for reuse. Small modules, not
                                              very interdependent ... sounds good to me. That part, we are
                                              commanded to do.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              www.xprogramming.com/blog
                                              Replacing an on-site customer with some use cases is about as effective
                                              as replacing a hug from your Mom with a friendly note.
                                            • J. B. Rainsberger
                                              ... I ask organizations to consider an internal open source model for promoting reusable code across projects. When two teams notice they share some code in
                                              Message 22 of 24 , Apr 29 12:38 PM
                                              View Source
                                              • 0 Attachment
                                                On 2009-04-09, at 04:03 , Brandon Olivares wrote:

                                                > As far as I understand it, XP discourages assuming something is
                                                > going to be
                                                > needed until you actually get to that point where it is needed. Also
                                                > according to my understanding, that includes abstracting code to be
                                                > more
                                                > general for reuse, until there is duplication, and then it can be
                                                > refactored.
                                                >
                                                > So, what about reuse across projects? That'd be duplication, but not
                                                > within
                                                > the same project.
                                                >
                                                > I've put about 30 hours into a part of this project I'm working on
                                                > that I
                                                > really think could be reused, which is why I'm curious about this.
                                                > Surely
                                                > reuse across projects can save a lot of time.
                                                >
                                                > So how do you handle this, when you're working on a new project, and
                                                > there's
                                                > a part that is very similar to something in another project? How do
                                                > you know
                                                > when to abstract it for better reuse?
                                                >
                                                I ask organizations to consider an "internal open source" model for
                                                promoting reusable code across projects. When two teams notice they
                                                share some code in common, they extract a library or framework,
                                                publish it to the intranet, then promote it to the rest of the
                                                organization. Sometimes those projects take on a life of their own;
                                                sometimes better projects eclipse them; sometimes weird stuff happens.
                                                I strongly encourage those organizations to make cross-project
                                                collaboration happen, which can be as simple as a Lunch and Learn once
                                                per month and as elaborate as an internal Open Space-based Tech Fair.

                                                Take care.
                                                ----
                                                J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                                Your guide to software craftsmanship
                                                JUnit Recipes: Practical Methods for Programmer Testing
                                                2005 Gordon Pask Award for contributions to Agile Software Practice
                                              • geoffrey_slinker
                                                There should be someone/some group that says they want to reuse the code. You may have to advertise to let developers know the code exists. Get up and walk
                                                Message 23 of 24 , Apr 29 4:29 PM
                                                View Source
                                                • 0 Attachment
                                                  There should be someone/some group that says they want to reuse the code. You may have to advertise to let developers know the code exists. Get up and walk around and talk about it. You may even have an idea of the exact developers that would want this new code. Changing code to fit the needs of an imaginary user doesn't seem prudent to me.

                                                  Code that is very similar to existing code is still just similar and not the same. For instance often code that is similar is bunched together and an additional parameter is added to the method and then inside the method is some decision logic like an if statement so that the code does each similar thing. I personally do not like this because code should have specific responsibilities and as few responsibilities as possible. If you are in an object oriented language you still have to be careful because similar is still not the same. In OO you can ask yourself, "If I am going to use inheritence then is this a case of static subtyping or runtime/behavior subtyping?"

                                                  (http://home.comcast.net/~gslinker/maverick/OOModeling.html)

                                                  There are many justifications for not reusing code. Your environment will determine if those justifications are sufficient to cause you to have duplicate code. In this case I constrain duplicate code to be identical code or identical interfaces implementations that pass the same set of unit tests.

                                                  So, if you have a specific additional customer and the code is identical then you can propose to have the code shared.

                                                  If you have a specific additional customer and the code is similar to other code then a conversation is needed to determine if the requirements, models, and domain are the same and if some base classes or interfaces should be made and if this is static subtyping or runtime/behavior subtyping. (runtime behavior can be done with virtual methods, with delegates and the strategy pattern, etc...)

                                                  Geoff
                                                  -------------------------------------------------------------------
                                                  http://digerati-illuminatus.blogspot.com/
                                                  http://mavericksoftwaredevelopment.blogspot.com/

                                                  > I've put about 30 hours into a part of this project I'm working on that I
                                                  > really think could be reused, which is why I'm curious about this. Surely
                                                  > reuse across projects can save a lot of time.
                                                  >
                                                  > So how do you handle this, when you're working on a new project, and there's
                                                  > a part that is very similar to something in another project? How do you know
                                                  > when to abstract it for better reuse?
                                                  >
                                                  > Thanks,
                                                  > Brandon
                                                  >
                                                • Ron Jeffries
                                                  Hello, geoffrey_slinker. On Wednesday, April 29, 2009, at 7:29:31 ... If code is similar but not the same, I like to make it the same then remove the
                                                  Message 24 of 24 , Apr 29 5:36 PM
                                                  View Source
                                                  • 0 Attachment
                                                    Hello, geoffrey_slinker. On Wednesday, April 29, 2009, at 7:29:31
                                                    PM, you wrote:

                                                    > Code that is very similar to existing code is still just similar
                                                    > and not the same. For instance often code that is similar is
                                                    > bunched together and an additional parameter is added to the
                                                    > method and then inside the method is some decision logic like an
                                                    > if statement so that the code does each similar thing. I
                                                    > personally do not like this because code should have specific
                                                    > responsibilities and as few responsibilities as possible. If you
                                                    > are in an object oriented language you still have to be careful
                                                    > because similar is still not the same. In OO you can ask yourself,
                                                    > "If I am going to use inheritence then is this a case of static
                                                    > subtyping or runtime/behavior subtyping?"

                                                    If code is similar but not the same, I like to make it the same then
                                                    remove the duplication.

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    www.xprogramming.com/blog
                                                    Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.