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

Individual -vs- Collective Code Ownership -- must it be an either/or proposition?

Expand Messages
  • Brad Appleton
    See Comments?/Thoughts? -- Brad Appleton www.bradapp.net Software
    Message 1 of 23 , May 11 12:12 AM
    • 0 Attachment
      See <http://bradapp.blogspot.com/2005/03/individual-vs-collective-code.html>

      Comments?/Thoughts?
      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep" --Robert Frost
    • Lasse Koskela
      ... Well, it s not much of a risk to just throw a blanket answer about extremes rarely being the optimum in real life. Life isn t black-and-white -- why should
      Message 2 of 23 , May 11 1:08 AM
      • 0 Attachment
        On 5/11/05, Brad Appleton <bradpro@...> wrote:
        > See <http://bradapp.blogspot.com/2005/03/individual-vs-collective-code.html>
        >
        > Comments?/Thoughts?

        Well, it's not much of a risk to just throw a blanket answer about
        extremes rarely being the optimum in real life. Life isn't
        black-and-white -- why should a social practice such as code ownership
        be?

        -Lasse-
      • Brad Appleton
        ... Agree. It s just that I too often see it discussed as if it were, especially when it s one of those our way is better than your way sort of things. Most
        Message 3 of 23 , May 11 9:29 PM
        • 0 Attachment
          Lasse Koskela wrote:
          > On 5/11/05, Brad Appleton <bradpro@...> wrote:
          > > See
          > <http://bradapp.blogspot.com/2005/03/individual-vs-collective-code.html>
          > >
          > > Comments?/Thoughts?
          >
          > Well, it's not much of a risk to just throw a blanket answer about
          > extremes rarely being the optimum in real life. Life isn't
          > black-and-white -- why should a social practice such as code ownership
          > be?

          Agree. It's just that I too often see it discussed as if it were,
          especially when it's one of those "our way is better than your way" sort
          of things. Most of the times I see either one discussed or described its
          usually the one of the extreme forms. I felt the need for a dose of
          reality, even tho some might be wanting to see a "stance" firmly on one
          side or the other and feel its "wimping out" not to do so.

          I think sometimes the "riskier stance" is to stand seemingly alone in
          the middle-ground rather than choosing a side and set of supporters.

          --
          Brad Appleton <brad@...> www.bradapp.net
          Software CM Patterns (www.scmpatterns.com)
          Effective Teamwork, Practical Integration
          "And miles to go before I sleep" --Robert Frost
        • Ron Jeffries
          ... Well, my friend, you are sure one h*ll of a risk-taker, then. Thanks for keeping us all from going binary! Ron Jeffries www.XProgramming.com Reason is and
          Message 4 of 23 , May 12 3:10 AM
          • 0 Attachment
            On Thursday, May 12, 2005, at 12:29:48 AM, Brad Appleton wrote:

            > I think sometimes the "riskier stance" is to stand seemingly alone in
            > the middle-ground rather than choosing a side and set of supporters.

            Well, my friend, you are sure one h*ll of a risk-taker, then. Thanks
            for keeping us all from going binary!

            Ron Jeffries
            www.XProgramming.com
            Reason is and ought only to be the slave of the passions. -- David Hume
          • Brad Appleton
            Based on previous feedback Ive tried to revise my description and expand my thoughts somewhat regarding stewardship and individual-vs-collective ownership.
            Message 5 of 23 , Jun 3, 2005
            • 0 Attachment
              Based on previous feedback Ive tried to revise my description and expand
              my thoughts somewhat regarding "stewardship" and
              individual-vs-collective ownership.

              See
              <http://bradapp.blogspot.com/2005/05/situational-ownership-code-stewardship.html>

              --
              Brad Appleton <brad@...> www.bradapp.net
              Software CM Patterns (www.scmpatterns.com)
              Effective Teamwork, Practical Integration
              "And miles to go before I sleep" --Robert Frost
            • Brad Appleton
              [I just blogged on this at http://blog.bradapp.net/] I came up with this when I was thinking about what some of the GoF Design Principles might mean in the
              Message 6 of 23 , Aug 2, 2005
              • 0 Attachment
                [I just blogged on this at http://blog.bradapp.net/]

                I came up with this when I was thinking about what some of the GoF
                Design Principles might mean in the domain of "process design" as
                opposed to software design. In one case I tried to translate "program to
                an interface, not an implementation" into "CM to an interface, not an
                implementation (see previous week's blog-entry). Then thinking about the
                customer-relationship aspect of it the following week got me thinking
                about this:

                -----[begin excerpt from http://blog.bradapp.net/]-----

                Often times, the process and procedures that development must follow
                in order to comply with CM needs were developed by the people who
                receive the outputs of development but who dont necessarily perform the
                development activities themselves. These process-area experts are the
                process designers and the developers are the end-users of their process.

                The conclusion of "CM to an interface, not an implementation" was to
                essentially invert or "flip" the relationship between who is the process
                "producer" and who is its "customer" ... Those who receive the outputs
                of that process are its customers, and they get to specify the
                requirements, but not the implementation ...

                * Upstream Development procedures should not depend on downstream
                CM procedures, both should depend upon the abstract interfaces
                represented by development's exit criteria and CM's entry criteria.

                * Procedures should not be designed for their practitioners by the
                upstream customer of their results, Practitioners should design their
                own procedures to meet the requirements of their upstream customers.

                -----[end excerpt from http://blog.bradapp.net]-----

                Thus far, Im not yet convinced that it is a "bona fide" principle as
                opposed to something that "sounds good but often crashes & burns in
                reality". I'd be interested in what others here think about it (pro or
                con) and why.

                --
                Brad Appleton <brad@...> www.bradapp.net
                Software CM Patterns (www.scmpatterns.com)
                Effective Teamwork, Practical Integration
                "And miles to go before I sleep" --Robert Frost
              • Brad Appleton
                Ive been trying to come up with a set of principles of Agile CM (see http://blog.bradapp.net), some of which are analogous to Uncle Bob s Principles of OOD
                Message 7 of 23 , Aug 31, 2005
                • 0 Attachment
                  Ive been trying to come up with a set of principles of "Agile CM" (see
                  http://blog.bradapp.net), some of which are analogous to "Uncle Bob's"
                  Principles of OOD (see
                  http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign)

                  Uncle Bob's "Package Cohesion Principles" are:
                  REP: The Release Reuse Equivalency Principle
                  -- The granule of reuse is the granule of release.
                  CCP: The Common Closure Principle
                  -- Classes that change together are packaged together.
                  CRP: The Common Reuse Principle
                  -- Classes that are used together are packaged together.

                  In some ways, a "class" is analogous to a "configuration" in a version
                  control system, and the smallest "consistent configuration" would be the
                  set of revisions of files/elements that are "committed" to the codeline
                  as a single "transaction".

                  If that is a valid analogy, then I think it would translate into change
                  packaging/commit principles as follows:

                  The Test/Commit Equivalency Principle
                  -- The granule of test is the granule of commit

                  The Change Closure Principle
                  -- Files that change together are committed together

                  The Test Closure Principle
                  -- Changes that are tested together are committed together

                  Comments? Thoughts? Should these always "hold true" in your experience?
                  When shouldnt they? (and why?)

                  Oh - and feel free to suggest better names if you dont like the ones I
                  used :-)
                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep" --Robert Frost
                • Curtis Cooley
                  ... I really like the way this is going though. What about No Partial Commits. I ve seen teams burned on this over and over, where some programmer, or even
                  Message 8 of 23 , Aug 31, 2005
                  • 0 Attachment
                    On 8/31/05, Brad Appleton <bradpro@...> wrote:
                    >
                    > If that is a valid analogy, then I think it would translate into change
                    > packaging/commit principles as follows:
                    >
                    > The Test/Commit Equivalency Principle
                    > -- The granule of test is the granule of commit
                    >
                    > The Change Closure Principle
                    > -- Files that change together are committed together
                    >
                    > The Test Closure Principle
                    > -- Changes that are tested together are committed together
                    >
                    > I don't fully understand the difference between TEP and TCP.

                    I really like the way this is going though.

                    What about No Partial Commits. I've seen teams burned on this over and over,
                    where some programmer, or even worse some pair, decides to only commit a
                    portion of the files they have changed. More often then not, this leads to
                    everyone who updates being broken. Is this meant to be covered under CCP?

                    Does TCP cover continuous integration? I think it does because I read it as
                    commit when the tests are green.

                    To be honest, when I first read the post my first reaction was this is just
                    a bunch of unnecessary overhead, but after digesting the principles a little
                    more, I think it's a really really good idea.
                    --
                    Curtis Cooley
                    curtis.cooley@...


                    [Non-text portions of this message have been removed]
                  • Brad Appleton
                    ... TEP says to commit only testable increments of changes. And that the smallest testable increment is the smallest thing change to attempt to commit.
                    Message 9 of 23 , Aug 31, 2005
                    • 0 Attachment
                      > On 8/31/05, Brad Appleton <bradpro@...> wrote:
                      >
                      >>If that is a valid analogy, then I think it would translate into change
                      >>packaging/commit principles as follows:
                      >>
                      >>The Test/Commit Equivalency Principle
                      >>-- The granule of test is the granule of commit
                      >>
                      >>The Change Closure Principle
                      >>-- Files that change together are committed together
                      >>
                      >>The Test Closure Principle
                      >>-- Changes that are tested together are committed together
                      >>
                      >>I don't fully understand the difference between TEP and TCP.

                      TEP says to commit only testable increments of changes. And that the
                      smallest testable increment is the smallest thing "change" to attempt to
                      commit. Commiting anything smaller than that would likely break the
                      codeline/build.

                      TCP is kind of ambiguous and Im trying to figure it out myself. One
                      possibility is it might mean that sets of changes/edits that are
                      "verified" by the same tests should be committed together.

                      Suppose I have modifications M1 and M2 and the same tests "T" verify M1
                      and M2. Then TEP would say dont commit anything smaller than M1 or M2,
                      and TCP would say commit M1+M2 at the same time instead of separately.
                      So TEP would set a lower-bound on commit size and TCP would set
                      something higher than that.

                      Now if it were the case that T could be subdivided into disjoint subsets
                      T1 and T2, such that T1 verifies M1 and T2 verifies M2, then it would be
                      okay to commit M1 and M2 separately, and even independently (i.e.
                      concurrently in parallel). But if T could not be divided into such
                      disjoint sets, meaning the intersection of T1 and T2 was non-empty, then
                      if their intersection was the same as all of T, it means M1+M2 must be
                      committed together in one transaction. Otherwise I would have to commit
                      one, and then the other consecutively (and I couldnt develop+commit them
                      concurrently in parallel)

                      Or maybe TCP doesnt mean that at all and Im simply trying to take an
                      analogy/translation way too far.

                      --
                      Brad Appleton <brad@...> www.bradapp.net
                      Software CM Patterns (www.scmpatterns.com)
                      Effective Teamwork, Practical Integration
                      "And miles to go before I sleep" --Robert Frost
                    • Brad Appleton
                      ... Thanks! Basically Im trying to ferret out the rules of dependency management for how one ought to do version control. Uncle Bob did a great job of
                      Message 10 of 23 , Aug 31, 2005
                      • 0 Attachment
                        Curtis Cooley wrote:
                        > On 8/31/05, Brad Appleton <bradpro@...> wrote:
                        >
                        >>If that is a valid analogy, then I think it would translate into change
                        >>packaging/commit principles as follows:
                        >>
                        >>The Test/Commit Equivalency Principle
                        >>-- The granule of test is the granule of commit
                        >>
                        >>The Change Closure Principle
                        >>-- Files that change together are committed together
                        >>
                        >>The Test Closure Principle
                        >>-- Changes that are tested together are committed together
                        >>
                        > I really like the way this is going though.

                        Thanks! Basically Im trying to ferret out the rules of dependency
                        management for how one ought to do version control. Uncle Bob did a
                        great job of dependency management principles for OO design. Im trying
                        to see if similar principles can be derived for the use of baselines,
                        codelines, branching/merging, and workspaces.

                        (As an example, "branching" is sorta kinda like inheritance. And we all
                        know that multiple inheritance is generally a bad idea and usually a
                        smell of some kind. The same is true of multiple codelines IMHO)

                        > What about No Partial Commits.

                        Yes! I think this is what TEP and CCP are getting at. Only they're
                        defining the smallest possible "allowable" granule of commit - so
                        anything less than that is, by definition, "partial". The next question
                        is, is anything bigger than that "too big?"


                        > Does TCP cover continuous integration? I think it does because I read it as
                        > commit when the tests are green.

                        I think if TCP is intepreted as setting both a minimum *and* maximum
                        commit-size (rather than just a minimum), then it probably implies
                        continuous integration.

                        > To be honest, when I first read the post my first reaction was this is just
                        > a bunch of unnecessary overhead, but after digesting the principles a little
                        > more, I think it's a really really good idea.

                        Cool! Then I encourage you to peek at http://blog.bradapp.net for my
                        stab at some of the first and most fundamental principles:

                        The Baseline Reproducibility Principle
                        -- if we released the code, we have to be able to reproduce it

                        The Baseline Identification Principle
                        -- If we released, and if we have to be able to reproduce it, then we
                        should give it a unique name that identifies what we released, and the
                        set of objects/revisions we used to build it.

                        The Baseline Immutability Principle
                        -- If we release it, and if we give it a name, then that name must
                        always and forever more refer to the same set of objects/revisions. I
                        cant later change one or more of the objects and claim it is still the
                        same baseline. If I make a change, the result must be a new
                        configuration, it cant be the same one that I had just baselined.


                        Right now Im starting with the most basic/simple stuff.
                        * BRP implies I should put the code under version control in a repository

                        * BIdP implies I should label/tag the state of the code I used to create
                        the release

                        * BImP says once I have tagged/labeled the code *and* released the
                        corresponding software, then the "tag" is "frozen" (note Im not saying
                        the code is frozen; Im saying the set of files+versions associated with
                        the tag must be frozen. The only time it should ever change is if I
                        neglected to tag something that I really should have, incorrectly tagged
                        something I shouldnt have, or tagged the wrong version)

                        Those are all pretty basic. I dont think there's anything controversial
                        about them.

                        --
                        Brad Appleton <brad@...> www.bradapp.net
                        Software CM Patterns (www.scmpatterns.com)
                        Effective Teamwork, Practical Integration
                        "And miles to go before I sleep" --Robert Frost
                      • Dean Wampler
                        ... One quibble, Martin actually regards the package (or depending on your preferred language, namespace , module , component ...), not class as the
                        Message 11 of 23 , Aug 31, 2005
                        • 0 Attachment
                          Brad Appleton wrote:
                          > ...
                          >
                          > In some ways, a "class" is analogous to a "configuration" in a version
                          > control system, and the smallest "consistent configuration" would be the
                          > set of revisions of files/elements that are "committed" to the codeline
                          > as a single "transaction".
                          >
                          > ...

                          One quibble, Martin actually regards the "package" (or depending on your
                          preferred language, "namespace", "module", "component"...), not "class"
                          as the granule of management. This is because individual classes are
                          rarely so decoupled from all other classes that they are granular where
                          release management is concerned. However, small groups of classes that
                          are, together, self-cohesive but loosely coupled with other "groups"
                          make the best "granules".

                          So, "package" is analogous to a "configuration"....

                          dean

                          --
                          Dean Wampler, Ph.D.
                          dean at aspectprogramming.com
                          http://www.aspectprogramming.com
                          http://www.contract4j.org
                          I want my tombstone to say:
                          Unknown Application Error in Dean Wampler.exe.
                          Application Terminated.
                          [Okay] [Cancel]
                        • Curtis Cooley
                          ... is released, don t migrate the tag. Cvs allows one to migrate tags. Does this principle say that is a bad idea? -- Curtis Cooley curtis.cooley@gmail.com
                          Message 12 of 23 , Sep 1, 2005
                          • 0 Attachment
                            On 8/31/05, Brad Appleton <bradpro@...> wrote:
                            >
                            > * BImP says once I have tagged/labeled the code *and* released the
                            > corresponding software, then the "tag" is "frozen" (note Im not saying
                            > the code is frozen; Im saying the set of files+versions associated with
                            > the tag must be frozen. The only time it should ever change is if I
                            > neglected to tag something that I really should have, incorrectly tagged
                            > something I shouldnt have, or tagged the wrong version)
                            >
                            > If I understand this correctly, then you are saying once a tagged version
                            is released, don't migrate the tag. Cvs allows one to migrate tags. Does
                            this principle say that is a bad idea?
                            --
                            Curtis Cooley
                            curtis.cooley@...


                            [Non-text portions of this message have been removed]
                          • Dean Wampler
                            ... I use two kinds of tags in CVS, milestone tags, which should never be moved, and latest tags that move to the latest versions on the integration branches
                            Message 13 of 23 , Sep 1, 2005
                            • 0 Attachment
                              Curtis Cooley wrote:
                              > On 8/31/05, Brad Appleton <bradpro@...> wrote:
                              >
                              >>* BImP says once I have tagged/labeled the code *and* released the
                              >>corresponding software, then the "tag" is "frozen" (note Im not saying
                              >>the code is frozen; Im saying the set of files+versions associated with
                              >>the tag must be frozen. The only time it should ever change is if I
                              >>neglected to tag something that I really should have, incorrectly tagged
                              >>something I shouldnt have, or tagged the wrong version)
                              >>
                              >>If I understand this correctly, then you are saying once a tagged version
                              >
                              > is released, don't migrate the tag. Cvs allows one to migrate tags. Does
                              > this principle say that is a bad idea?

                              I use two kinds of tags in CVS, milestone tags, which should never be
                              moved, and "latest" tags that move to the latest versions on the
                              integration branches after the each successful build.

                              dean

                              --
                              Dean Wampler, Ph.D.
                              dean at aspectprogramming.com
                              http://www.aspectprogramming.com
                              http://www.contract4j.org
                              I want my tombstone to say:
                              Unknown Application Error in Dean Wampler.exe.
                              Application Terminated.
                              [Okay] [Cancel]
                            • Colin Putney
                              ... I think it s more than that - anything larger would tie together otherwise independent changes. If we take TEP to its logical extreme, it implies that we
                              Message 14 of 23 , Sep 1, 2005
                              • 0 Attachment
                                Brad Appleton wrote:
                                >>On 8/31/05, Brad Appleton <bradpro@...> wrote:
                                >>
                                >>
                                >>>If that is a valid analogy, then I think it would translate into change
                                >>>packaging/commit principles as follows:
                                >>>
                                >>>The Test/Commit Equivalency Principle
                                >>>-- The granule of test is the granule of commit
                                >>>
                                >>>The Change Closure Principle
                                >>>-- Files that change together are committed together
                                >>>
                                >>>The Test Closure Principle
                                >>>-- Changes that are tested together are committed together
                                >>>
                                >>>I don't fully understand the difference between TEP and TCP.
                                >
                                >
                                > TEP says to commit only testable increments of changes. And that the
                                > smallest testable increment is the smallest thing "change" to attempt to
                                > commit. Commiting anything smaller than that would likely break the
                                > codeline/build.

                                I think it's more than that - anything larger would tie together
                                otherwise independent changes. If we take TEP to its logical extreme, it
                                implies that we should commit every time you get a green bar. We might
                                not want to go that far when practising TDD - there's no point in
                                committing the intermediate stages of the "fake it 'til you make it,"
                                strategy, for example.

                                Here's another interesting aspect to TCP: if we follow it, are the tests
                                committed with the changes they test, or separately? I tend to commit
                                both changes and their tests in a single commit, but if we pursue the
                                idea that tests are executable specifications, it might make sense to
                                version them independently. Then it becomes possible to test different
                                versions of the production code against different versions of the
                                specification.

                                Colin
                              • Brad Appleton
                                ... Thanks Dean I believe you are correct that a package would correspond to a configuration of things - and in fact in the field of SCM there is an
                                Message 15 of 23 , Sep 1, 2005
                                • 0 Attachment
                                  Dean Wampler wrote:
                                  > One quibble, Martin actually regards the "package" (or depending on your
                                  > preferred language, "namespace", "module", "component"...), not "class"
                                  > as the granule of management.

                                  Thanks Dean

                                  I believe you are correct that a package would correspond to a
                                  "configuration" of "things" - and in fact in the field of SCM there is
                                  an existing notion of a so called "change package" (sometimes called a
                                  "change set" even tho there is a subtle difference between change-sets
                                  and change-packages). And in fact a "change package" maps _exactly_ to
                                  what Martin calls a "package" (IMHO of course :-).

                                  From a CM version-control perspective, a "class" would actually
                                  correspond to a codeline, a subclass would be a branch of a new
                                  codeline, and an instance of a class (object) would correspond to a
                                  configuration

                                  The difference between the configuration represented by a "package"
                                  versus the configuration represented by an "object" is that an "object"
                                  would correspond to a configuration of the codeline. A "package"
                                  corresponds to the configuration of one (or more?) changes. The former
                                  is a configuration of "physical" change elements, the latter is more
                                  like a configuration of "logical" change elements.

                                  --
                                  Brad Appleton <brad@...> www.bradapp.net
                                  Software CM Patterns (www.scmpatterns.com)
                                  Effective Teamwork, Practical Integration
                                  "And miles to go before I sleep" --Robert Frost
                                • Brad Appleton
                                  ... Hi Curtis! If I understand what you mean by migrating a tag then I think Ive also heard that referred to as a floating tag . A floating tag is typically
                                  Message 16 of 23 , Sep 1, 2005
                                  • 0 Attachment
                                    Curtis Cooley wrote:
                                    > On 8/31/05, Brad Appleton <bradpro@...> wrote:
                                    >
                                    >>* BImP says once I have tagged/labeled the code *and* released the
                                    >>corresponding software, then the "tag" is "frozen" (note Im not saying
                                    >>the code is frozen; Im saying the set of files+versions associated with
                                    >>the tag must be frozen. The only time it should ever change is if I
                                    >>neglected to tag something that I really should have, incorrectly tagged
                                    >>something I shouldnt have, or tagged the wrong version)
                                    >>
                                    >>If I understand this correctly, then you are saying once a tagged version
                                    >
                                    > is released, don't migrate the tag. Cvs allows one to migrate tags. Does
                                    > this principle say that is a bad idea?

                                    Hi Curtis!

                                    If I understand what you mean by "migrating a tag" then I think Ive also
                                    heard that referred to as a "floating tag". A floating tag is typically
                                    used to indicate "the latest baseline" or "last good build". So rather
                                    than being a baselined configuration, in theory it's really a reference
                                    to a configuration. Migrating the floating tag is merely updating the
                                    "reference" to point to the new baseline/configuration.

                                    Hence I dont consider a floating tag to be a configuration. It supports
                                    the concept that CM calls "current configuration", which is "the most
                                    recent baselined configuration PLUS the latest 'approved' changes."

                                    So I would say that BImP isnt talking about floating tags, because
                                    "current configuration" isnt necessairly a baseline, and its purprose is
                                    not to identify a particular baseline and always that baseline - its
                                    purpose is to identify which configuration is the "latest and greatest"
                                    at a particular point in time, and it is intentionally dynamic (unlike a
                                    "baseline").

                                    Your question does reveal an extremely common miscommunication that
                                    happens regarding different interpretations of the term "the baseline".
                                    Some use "the baseline" to to mean "the LATEST baseline", others use it
                                    to mean a particular baseline. (So I guess some call it by "value" and
                                    others call it by "reference" :-)

                                    --
                                    Brad Appleton <brad@...> www.bradapp.net
                                    Software CM Patterns (www.scmpatterns.com)
                                    Effective Teamwork, Practical Integration
                                    "And miles to go before I sleep" --Robert Frost
                                  • Brad Appleton
                                    Hi Colin! ... I think that all by itself without anything else, TCP speaks only to what the smallest building block of a commit should be. I dont think that
                                    Message 17 of 23 , Sep 2, 2005
                                    • 0 Attachment
                                      Hi Colin!

                                      Colin Putney wrote:
                                      > Brad Appleton wrote:
                                      >
                                      >>>On 8/31/05, Brad Appleton <bradpro@...> wrote:
                                      >>>
                                      >>>
                                      >>>
                                      >>>>If that is a valid analogy, then I think it would translate into change
                                      >>>>packaging/commit principles as follows:
                                      >>>>
                                      >>>>The Test/Commit Equivalency Principle
                                      >>>>-- The granule of test is the granule of commit
                                      >>>>
                                      >>>>The Change Closure Principle
                                      >>>>-- Files that change together are committed together
                                      >>>>
                                      >>>>The Test Closure Principle
                                      >>>>-- Changes that are tested together are committed together
                                      >>>>
                                      >>>>I don't fully understand the difference between TEP and TCP.
                                      >>
                                      >>
                                      >>TEP says to commit only testable increments of changes. And that the
                                      >>smallest testable increment is the smallest thing "change" to attempt to
                                      >>commit. Commiting anything smaller than that would likely break the
                                      >>codeline/build.
                                      >
                                      >
                                      > I think it's more than that - anything larger would tie together
                                      > otherwise independent changes. If we take TEP to its logical extreme, it
                                      > implies that we should commit every time you get a green bar. We might
                                      > not want to go that far when practising TDD - there's no point in
                                      > committing the intermediate stages of the "fake it 'til you make it,"
                                      > strategy, for example.

                                      I think that all by itself without anything else, TCP speaks only to
                                      what the smallest "building block" of a commit should be. I dont think
                                      that by itself it claims that we should not commit anything larger -
                                      only that we should only ever commit in "whole number" of testable "units".

                                      I think that once coupled with a particular set of values (like XP for
                                      example) it would definitely suggest commiting in the most "extreme"
                                      granularity feasible.

                                      > Here's another interesting aspect to TCP: if we follow it, are the tests
                                      > committed with the changes they test, or separately?

                                      Excellent question! Im not sure I have a good answer for it. I think the
                                      principles mentioned so far dont give a full answer for it. However,
                                      there is another principle I havent mentioned yet ...

                                      I havent decided whether to call it the "Codeline Consistency Principle"
                                      or the "Codeline Integrity Principle" but the gist of it is what we mean
                                      when we say "Don't break the build!" (only stated in the positive rather
                                      than the negative :-).

                                      So I would look to the Codeline Consistency/Integrity Principle to
                                      answer the question of whether (when practicing TDD) to commit the tests
                                      separately before committing the code. If committing the tests
                                      separately (prior to committing the code that passed the tests) would
                                      cause me to break the codeline for my teammates, then I think I should
                                      not do it.

                                      BTW, in case anyone was wondering, my "Baseline Immutability Principle"
                                      was really just a rephrasing of "The Open/Closed Principle" applied to
                                      baselines. If a "baseline" is "open for extension, but closed for
                                      modification", it means that any change to a baselined configuration is
                                      no longer the same configuration, it is instead a new configuration that
                                      was derived from the previous one.

                                      This use of "derived configuration" opens the door to some possible
                                      interpretation of The Liskov Substitution Principle (LSP). If I try to
                                      "translate" the LSP by applying it for a "baseline" (as opposed to a
                                      codeline for example) then it's saying a newly promoted "baseline"
                                      should in some regard be "substitutible" for it's predecessor baseline.

                                      The question is, what does "substitutible" rightly mean in this case.
                                      Whatever it means, I think applying LSP to baselines (or to "current
                                      configuration") actually supports the notion of the floating/migrating
                                      tag that you and Curtis had referred to earlier. By floating/migrating
                                      the tag, I am "substituting" the newly "blessed" configuration for the
                                      previously "blessed" configuration. And I am therefore claiming it
                                      preserves some important "interface".

                                      The question is what is it preserving? Is it preserving functionality?
                                      consistency/integrity? something else? Would it be a new principle
                                      (e.g., "Configuration/Baseline Promotion Principle") or would it simply
                                      be a restatement of the codeline consistency/integrity principle that
                                      says to preserve the codeline "invariant" (the codeline commit policy).

                                      > both changes and their tests in a single commit, but if we pursue the
                                      > idea that tests are executable specifications, it might make sense to
                                      > version them independently. Then it becomes possible to test different
                                      > versions of the production code against different versions of the
                                      > specification.

                                      I like that idea a lot! (Provided of course that committing tests
                                      separately is done in a way that wont "break the build" :-)

                                      --
                                      Brad Appleton <brad@...> www.bradapp.net
                                      Software CM Patterns (www.scmpatterns.com)
                                      Effective Teamwork, Practical Integration
                                      "And miles to go before I sleep" --Robert Frost
                                    • Colin Putney
                                      ... Ok, if that s the case, is there anything more to this than don t break the build? That seems to be the gist of this entire thread actually, although you
                                      Message 18 of 23 , Sep 3, 2005
                                      • 0 Attachment
                                        On Sep 2, 2005, at 3:16 AM, Brad Appleton wrote:

                                        > I think that all by itself without anything else, TCP speaks only to
                                        > what the smallest "building block" of a commit should be. I dont think
                                        > that by itself it claims that we should not commit anything larger -
                                        > only that we should only ever commit in "whole number" of testable
                                        > "units".

                                        Ok, if that's the case, is there anything more to this than "don't
                                        break the build?" That seems to be the gist of this entire thread
                                        actually, although you did mention you prefer to make a positive
                                        statement. So how about this:

                                        Make all the tests pass before you commit.

                                        My question is this: what do your change packaging principles tell us
                                        that the above statement does not?

                                        Colin
                                      • Brad Appleton
                                        ... I think so. I think there is a statement in there about granularity. TCP says what the lower bound is. It might even say something about the upperbound
                                        Message 19 of 23 , Sep 4, 2005
                                        • 0 Attachment
                                          Colin Putney wrote:
                                          > On Sep 2, 2005, at 3:16 AM, Brad Appleton wrote:
                                          >
                                          >>I think that all by itself without anything else, TCP speaks only to
                                          >>what the smallest "building block" of a commit should be. I dont think
                                          >>that by itself it claims that we should not commit anything larger -
                                          >>only that we should only ever commit in "whole number" of testable
                                          >>"units".
                                          >
                                          >
                                          > Ok, if that's the case, is there anything more to this than "don't
                                          > break the build?"

                                          I think so. I think there is a statement in there about granularity. TCP
                                          says what the lower bound is. It might even say something about the
                                          upperbound that helps you know if youve found it, but it doesnt say what
                                          it is.

                                          I think that finding the upper bound will require putting several
                                          principles together. And then even still might require a project
                                          context-sensitive application of the principles to get the right upperbound.

                                          > So how about this:
                                          >
                                          > Make all the tests pass before you commit.

                                          That's a separate principle (The Codeline Integrity/Consistency
                                          Principle :-)

                                          > My question is this: what do your change packaging principles tell us
                                          > that the above statement does not?

                                          I dont think the change-packaging principles are so much about passing
                                          tests as they are about judging the granularity of a commit.

                                          One of the first and more important things it tells us is that commits
                                          should be task/behavior based rather than file-based. File-based checkin
                                          is still overwhelmingly the "norm" that I see for shops that are
                                          relatively "unseasoned" regarding version control. People do checkins of
                                          individual files rather than commits of their change/task.

                                          So that's the first and biggest hurdle I see the change-packaging
                                          principles as trying to clear. I guess for shops where that isnt already
                                          "obvious" the whole notion of "commit" (as opposed to "checkin") may
                                          seem alien.

                                          Somewhere in there, the size+granularity of a "commit" should be based
                                          primarily on project-oriented criteria more than file-oriented criteria.
                                          But frequency of commit has to be a factor in that too - and obviously
                                          build-time is going to play a decisive factor in commit frequency.

                                          In fact, a principle like codeline consistency/integrity ("dont break
                                          the build") might very well argue for making commit size+frequency to be
                                          larger rather than smaller. Because there may be a big difference in the
                                          time it takes for clean/full build and a "dirty"/incremental build. So I
                                          might need to balance TCEP with CCIP to arrive at a "good" decision
                                          regarding commit size+frequency and codeline "consistency".

                                          For example, perhaps I do "dirty" builds at commit-time, but still have
                                          to pass all the tests. And then maybe 2X a day there is an automatically
                                          scheduled "full build". That sort of arrangement might let me and my
                                          team commit several time per hour instead of just per day. (or maybe we
                                          have to figure out out yet another way to decrease the amount of time to
                                          do a full-build, or maybe we do a full-build but of one component
                                          instead of the entire system :-)

                                          --
                                          Brad Appleton <brad@...> www.bradapp.net
                                          Software CM Patterns (www.scmpatterns.com)
                                          Effective Teamwork, Practical Integration
                                          "And miles to go before I sleep" --Robert Frost
                                        • Anthony Williams
                                          ... I like to check tests in with the code that makes them pass; I don t think it makes sense to check in code that would break the build. Not only that, but I
                                          Message 20 of 23 , Sep 8, 2005
                                          • 0 Attachment
                                            Brad Appleton <bradpro@...> writes:
                                            > Colin Putney wrote:
                                            >> Here's another interesting aspect to TCP: if we follow it, are the tests
                                            >> committed with the changes they test, or separately?
                                            >
                                            > Excellent question! Im not sure I have a good answer for it. I think the
                                            > principles mentioned so far dont give a full answer for it. However,
                                            > there is another principle I havent mentioned yet ...
                                            >
                                            > I havent decided whether to call it the "Codeline Consistency Principle"
                                            > or the "Codeline Integrity Principle" but the gist of it is what we mean
                                            > when we say "Don't break the build!" (only stated in the positive rather
                                            > than the negative :-).
                                            >
                                            > So I would look to the Codeline Consistency/Integrity Principle to
                                            > answer the question of whether (when practicing TDD) to commit the tests
                                            > separately before committing the code. If committing the tests
                                            > separately (prior to committing the code that passed the tests) would
                                            > cause me to break the codeline for my teammates, then I think I should
                                            > not do it.

                                            I like to check tests in with the code that makes them pass; I don't think it
                                            makes sense to check in code that would break the build. Not only that, but I
                                            like to check the code+tests in *every time* I make the tests pass.

                                            I don't think it makes sense to check in changes smaller than that, and I'm
                                            not sure I would feel comfortable leaving it much longer --- it gives me
                                            greater confidence to make a change, knowing that I have working code under
                                            source control to roll back to, and that I won't lose a lot of work in doing
                                            so.

                                            Anthony
                                            --
                                            Anthony Williams
                                            Software Developer
                                            Just Software Solutions Ltd
                                            http://www.justsoftwaresolutions.co.uk
                                          • Brad Appleton
                                            Thanks to one and all for their comments. In my earlier attempt at translating Uncle Bob s package cohesion principles (see
                                            Message 21 of 23 , Sep 11, 2005
                                            • 0 Attachment
                                              Thanks to one and all for their comments. In my earlier attempt at
                                              translating Uncle Bob's package cohesion principles (see
                                              http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign)
                                              into version-control principle (see http://blog.bradapp.net) I think I
                                              tried to incorrectly translate "reuse" to "test".

                                              I still think that "release" translates to "promotion" (e.g. "commit")
                                              but I now think "reuse" is better translated to "integration":

                                              * The Promotion-Integration Equivalency Principle -- The granule of
                                              integration is the granule of promotion. (i.e., the smallest possible
                                              change that can be successfully integrated without breaking stuff)

                                              * The Change Closure Principle -- Elements that must be changed together
                                              are promoted together (implies task-level commit).

                                              * The Change Promotion Principle -- Elements that must be integrated
                                              together are promoted together.

                                              I think this discussion has also help me discover the "translation" for
                                              the Interface Segregation Principle (ISP): ISP states "Make
                                              fine-grained interfaces that are client-specific." If "integration" is
                                              reuse, then each atom/granule of change is an interface or "container"
                                              of the smallest possible unit of reuse.

                                              The smallest possible unit of logical change that I can "commit" that
                                              doesn't break the build/codeline would be a very specific, individually
                                              testable, piece of behavior. Granted, sometimes it might not be run-time
                                              behavior ... it could be build-time behavior, or behavior exhibited at
                                              some other binding time (see
                                              http://www.softwareproductlines.com/introduction/binding.html).

                                              This would yield the following translation of the ISP into the
                                              version-control domain:

                                              * The Change Separation Principle -- Make fine-grained incremental
                                              changes that are behavior-specific. (i.e., partition your task into
                                              minimal yet testable increments of behavior)

                                              I'm not thrilled about the name (please feel free to suggest a better
                                              one) but I think the above translation "works" quite well, and also
                                              speaks to "right-sizing" the amount of change that is committed to the
                                              codeline as an individual "transaction" of change.
                                              --
                                              Brad Appleton <brad@...> www.bradapp.net
                                              Software CM Patterns (www.scmpatterns.com)
                                              Effective Teamwork, Practical Integration
                                              "And miles to go before I sleep" --Robert Frost
                                            • Frank Schophuizen
                                              ... I still have strong doubts about reuse meaning integration . If we look at change propagation, then it consists of a number of steps: INNER CYCLE
                                              Message 22 of 23 , Sep 12, 2005
                                              • 0 Attachment
                                                > I think I
                                                > tried to incorrectly translate "reuse" to "test".
                                                >
                                                > I still think that "release" translates to
                                                > "promotion" (e.g. "commit")
                                                > but I now think "reuse" is better translated to
                                                > "integration":


                                                I still have strong doubts about "reuse" meaning
                                                "integration".

                                                If we look at change propagation, then it consists of
                                                a number of steps:

                                                INNER CYCLE (intra-project flow)

                                                Step 1.1: Make change in a private workspace
                                                Step 1.2: Transfer the change from the private
                                                workspace to a shared build configuration
                                                Step 1.3: Accept the current state of the shared build
                                                configuration
                                                Step 1.4: Transfer the changes from the shared build
                                                environment to the private workspace of other
                                                developers

                                                OUTER CYCLE (inter-project flow)

                                                Step 2.1: Accept a configuration (from the inner
                                                cycle)
                                                Step 2.2: Transfer the configuration to an another
                                                project
                                                Step 2.3: Accept the configuration (in the outer
                                                cycle)


                                                The inner cycle is typically a development project
                                                where a part of the total system is developed. During
                                                step 1.1, the changes may be "committed" to the CM
                                                repository, for example to work peer-to-peer (or in
                                                pairs) with other developers, possibly at a different
                                                location. So, I would call this a "commit", or "check
                                                in".
                                                Step 1.2 I would call a "task-level commit", "deliver"
                                                or "integrate".
                                                Step 1.3 I would call "promote" as it is only a change
                                                of the value of the configuration, without actually
                                                transferring anything to anywhere. In fact, the
                                                individual change loses its indivuality because it is
                                                being part of an integrated configuration (like a
                                                glass of water added to a bucket).
                                                Step 1.4 is what "reuse" would mean IMO. Developers
                                                will use the integrated configuration, rather than the
                                                individual change that was made in step 1.1. In UCM
                                                this is called "rebase", because in UCM the integrated
                                                and promoted configuration is called a "baseline" and
                                                developer change the foundation relative to which they
                                                make their individual changes (step 1.1).

                                                Step 2.1 and 2.3 I would call "promote" again.
                                                Step 2.2 I would call "release" or "publish" from the
                                                supplier side, or "in-take" from the consumer/client
                                                side. But in general, I would call it "integrate".


                                                In short: the term "reuse" typically applies to step
                                                1.4 (shared --> individual) and 2.2 (in the project
                                                --> outside the project). Since step 1.2 (individual
                                                --> shared) already is an "integration" step, I would
                                                rather call it "publish", "share" or even "rebase" (as
                                                UCM does, although UCM also knows inter-project
                                                "deliver").

                                                Regards,
                                                Frank.



                                                __________________________________
                                                Yahoo! Mail - PC Magazine Editors' Choice 2005
                                                http://mail.yahoo.com
                                              • Brad Appleton
                                                Thanks Frank. I think this is an important distinction between reusable and reused : * Reusable is (ideally) when we promote/commit/deliver our change. *
                                                Message 23 of 23 , Sep 12, 2005
                                                • 0 Attachment
                                                  Thanks Frank. I think this is an important distinction between
                                                  "reusable" and "reused":
                                                  * "Reusable" is (ideally) when we promote/commit/deliver our change.
                                                  * "Reused is when we rebase/update, or (re)initialize our workspace.

                                                  So even tho it may be true that the "granule" of promotion (being
                                                  reusable) is the granule "integration", it doesnt mean they both happen
                                                  at the same time.

                                                  This means something needs to make the important distinction between a
                                                  merge-out (e.g., export/deliver) versus a "merge-in" (e.g., import/rebase).

                                                  So I still somehow need to address some of these key differences:
                                                  * deliver/promote versus rebase/work-space update integration
                                                  * whether or not tip of the codeline == "current configuration"
                                                  * checkpointing (private versions) versus comitting (public publishing)
                                                  the state of a change


                                                  Frank Schophuizen wrote:
                                                  > > I think I
                                                  > > tried to incorrectly translate "reuse" to "test".
                                                  > >
                                                  > > I still think that "release" translates to
                                                  > > "promotion" (e.g. "commit")
                                                  > > but I now think "reuse" is better translated to
                                                  > > "integration":
                                                  >
                                                  >
                                                  > I still have strong doubts about "reuse" meaning
                                                  > "integration".
                                                  >
                                                  > If we look at change propagation, then it consists of
                                                  > a number of steps:
                                                  >
                                                  > INNER CYCLE (intra-project flow)
                                                  >
                                                  > Step 1.1: Make change in a private workspace
                                                  > Step 1.2: Transfer the change from the private
                                                  > workspace to a shared build configuration
                                                  > Step 1.3: Accept the current state of the shared build
                                                  > configuration
                                                  > Step 1.4: Transfer the changes from the shared build
                                                  > environment to the private workspace of other
                                                  > developers
                                                  >
                                                  > OUTER CYCLE (inter-project flow)
                                                  >
                                                  > Step 2.1: Accept a configuration (from the inner
                                                  > cycle)
                                                  > Step 2.2: Transfer the configuration to an another
                                                  > project
                                                  > Step 2.3: Accept the configuration (in the outer
                                                  > cycle)
                                                  >
                                                  >
                                                  > The inner cycle is typically a development project
                                                  > where a part of the total system is developed. During
                                                  > step 1.1, the changes may be "committed" to the CM
                                                  > repository, for example to work peer-to-peer (or in
                                                  > pairs) with other developers, possibly at a different
                                                  > location. So, I would call this a "commit", or "check
                                                  > in".
                                                  > Step 1.2 I would call a "task-level commit", "deliver"
                                                  > or "integrate".
                                                  > Step 1.3 I would call "promote" as it is only a change
                                                  > of the value of the configuration, without actually
                                                  > transferring anything to anywhere. In fact, the
                                                  > individual change loses its indivuality because it is
                                                  > being part of an integrated configuration (like a
                                                  > glass of water added to a bucket).
                                                  > Step 1.4 is what "reuse" would mean IMO. Developers
                                                  > will use the integrated configuration, rather than the
                                                  > individual change that was made in step 1.1. In UCM
                                                  > this is called "rebase", because in UCM the integrated
                                                  > and promoted configuration is called a "baseline" and
                                                  > developer change the foundation relative to which they
                                                  > make their individual changes (step 1.1).
                                                  >
                                                  > Step 2.1 and 2.3 I would call "promote" again.
                                                  > Step 2.2 I would call "release" or "publish" from the
                                                  > supplier side, or "in-take" from the consumer/client
                                                  > side. But in general, I would call it "integrate".
                                                  >
                                                  >
                                                  > In short: the term "reuse" typically applies to step
                                                  > 1.4 (shared --> individual) and 2.2 (in the project
                                                  > --> outside the project). Since step 1.2 (individual
                                                  > --> shared) already is an "integration" step, I would
                                                  > rather call it "publish", "share" or even "rebase" (as
                                                  > UCM does, although UCM also knows inter-project
                                                  > "deliver").
                                                  >
                                                  > Regards,
                                                  > Frank.
                                                  >
                                                  >
                                                  >
                                                  > __________________________________
                                                  > Yahoo! Mail - PC Magazine Editors' Choice 2005
                                                  > http://mail.yahoo.com
                                                  >
                                                  >
                                                  > SPONSORED LINKS
                                                  > Software configuration management
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Software+configuration+management&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=Jpk018q_VU59OJhamaqDtw>
                                                  > Development outsourcing software
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Development+outsourcing+software&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=dwNOIidk-2ueUap7wfHSiQ>
                                                  > Software development company
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Software+development+company&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=ehtVwa3ccaKlrgjdiLgqbQ>
                                                  >
                                                  > Configuration management tools
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Configuration+management+tools&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=OQIDTST5iTHLH5_c1JNy_g>
                                                  > Software configuration management tool
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Software+configuration+management+tool&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=lxov3Mj3hGTpaLo3FtOKTA>
                                                  > Software configuration management plan
                                                  > <http://groups.yahoo.com/gads?t=ms&k=Software+configuration+management+plan&w1=Software+configuration+management&w2=Development+outsourcing+software&w3=Software+development+company&w4=Configuration+management+tools&w5=Software+configuration+management+tool&w6=Software+configuration+management+plan&c=6&s=235&.sig=tDJ-omqZTfJ-UFFE2e7zeg>
                                                  >
                                                  >
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  > YAHOO! GROUPS LINKS
                                                  >
                                                  > * Visit your group "scm-patterns
                                                  > <http://groups.yahoo.com/group/scm-patterns>" on the web.
                                                  >
                                                  > * To unsubscribe from this group, send an email to:
                                                  > scm-patterns-unsubscribe@yahoogroups.com
                                                  > <mailto:scm-patterns-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                                                  >
                                                  > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                                                  > Service <http://docs.yahoo.com/info/terms/>.
                                                  >
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  >

                                                  --
                                                  Brad Appleton <brad@...> www.bradapp.net
                                                  Software CM Patterns (www.scmpatterns.com)
                                                  Effective Teamwork, Practical Integration
                                                  "And miles to go before I sleep" --Robert Frost
                                                Your message has been successfully submitted and would be delivered to recipients shortly.