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

Re: [XP] Does C++ unit testing become easier ?

Expand Messages
  • Phlip
    ... Raw TDD on new code should not use so many mock objects. Most mock objects should just be classes derived from production objects, with selected methods
    Message 1 of 29 , Dec 1, 2006
    • 0 Attachment
      Steven Woody wrote:

      > how may c++ guys there? for unit testing, i think object mocking
      > tools is a must. but mockpp is a daunting tool to use. is there any
      > bettern choice today?

      Raw TDD on new code should not use so many mock objects. Most mock objects
      should just be classes derived from production objects, with selected
      methods overrode.

      Raw TDD typically generates highly decouple code that needs few mocks.
      (There were huge threads here, summer and fall, discussing mock-abuse.)

      Some programmers migrate from Java or Python, where a mock object can
      automatically sprout its required methods. That's an easy crutch; try to
      write decoupled objects that don't need mocks of any kind.

      Expensive setup is a design smell.

      I have TDDed in C++ since '99, and I only heavily used mocking techniques
      when dealing with legacy code. And even then, I most frequently overrode
      production objects.

      --
      Phlip
      http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
    • Bill Caputo
      ... (snip) ... My experience is similar to Phlip s -- I too did most of my formative TDD in C++, and so developed several disciplines (by necessity) that I
      Message 2 of 29 , Dec 1, 2006
      • 0 Attachment
        On 12/1/06, Phlip <phlip2005@...> wrote:
        > Steven Woody wrote:
        >
        > > how may c++ guys there? for unit testing, i think object mocking
        > > tools is a must. but mockpp is a daunting tool to use. is there any
        > > bettern choice today?
        >
        (snip)
        > Some programmers migrate from Java or Python, where a mock object can
        > automatically sprout its required methods. That's an easy crutch; try to
        > write decoupled objects that don't need mocks of any kind.

        My experience is similar to Phlip's -- I too did most of my formative
        TDD in C++, and so developed several disciplines (by necessity) that I
        have often found missing in my Java/C# brethren who didn't have to
        worry about them as much:
        1) The ability to refactor very aggressively after every test (without
        a refactoring browser its the really the only way to keep up -- it
        also happens to be the best way to keep code clean).
        2) The ability to accurately decided what tests are needed for
        checking edge cases on inputs/outputs (necessary when working with
        pointers)
        3) The ability to write code that requires little or no mocking (as
        Phlip alluded to). Also, I still generally prefer to roll my own to
        using a mocking library, as I find it simpler in the early going, and
        more flexible/controllable later on. I do use mocking libraries at
        times, but I find the ability to do without liberating, not limiting.

        Until now I had only attributed the first two to my C++ days. And
        while I am glad to have tools like refactoring browsers and mocking
        frameworks, I would say not having to rely on them is a skill that
        those who never shipped code without them can't appreciate until they
        get stuck (i.e. I've witnessed many debates about what was
        refactorable/testable that on deeper consideration were based more on
        individual skills and tools rather than anything inherent in the
        code).

        I would expect going the other way (from Java/C# to C++) would thus
        probably be a lot harder (as with many other things about the
        languages).

        I guess my point is, if you focus on finding ways to make it simpler
        and less painful to test, perhaps by unlearning some of the techniques
        you've come to rely on in other languages, it will almost certainly
        pay big dividends for you when you go back, and you may even get to
        where you don't feel like you are less productive. :-)

        Best,
        Bill
      • Steven Woody
        ... it s interesting, but ... the problem is how to write decoupled code with few needs of object mocking. supposing i have three classes, C1, C2 and C3. a
        Message 3 of 29 , Dec 1, 2006
        • 0 Attachment
          On 12/2/06, Phlip <phlip2005@...> wrote:
          >
          >
          >
          >
          >
          >
          > Steven Woody wrote:
          >
          > > how may c++ guys there? for unit testing, i think object mocking
          > > tools is a must. but mockpp is a daunting tool to use. is there any
          > > bettern choice today?
          >
          > Raw TDD on new code should not use so many mock objects. Most mock objects
          > should just be classes derived from production objects, with selected
          > methods overrode.
          >
          > Raw TDD typically generates highly decouple code that needs few mocks.
          > (There were huge threads here, summer and fall, discussing mock-abuse.)
          >
          > Some programmers migrate from Java or Python, where a mock object can
          > automatically sprout its required methods. That's an easy crutch; try to
          > write decoupled objects that don't need mocks of any kind.
          >
          > Expensive setup is a design smell.
          >
          > I have TDDed in C++ since '99, and I only heavily used mocking techniques
          > when dealing with legacy code. And even then, I most frequently overrode
          > production objects.
          >

          it's interesting, but ... the problem is how to write decoupled code
          with few needs of object mocking. supposing i have three classes, C1,
          C2 and C3. a method of C1 uses a method of C2 and the method of C2
          calls C3 to print some result on some kind of output device. to test
          C1, real implemention of C2 has to already exist, the same applies to
          C3. and, more important, to check the C1's behavior, i have to
          finally check the C3's output, in many cases, i find it is teadious
          and impossible.

          i like to hear more suggestions on this subject. thank you.

          --
          woody

          then sun rose thinly from the sea and the old man could see the other
          boats, low on the water and well in toward the shore, spread out
          across the current.
        • Phlip
          ... You conflate two issues there. One is the domino theory, C1 - C2 - C3. The other is the proton problem. C3 affects hardware. (For my second TDD project
          Message 4 of 29 , Dec 1, 2006
          • 0 Attachment
            Steven Woody wrote:

            > it's interesting, but ... the problem is how to write decoupled code
            > with few needs of object mocking. supposing i have three classes, C1,
            > C2 and C3. a method of C1 uses a method of C2 and the method of C2
            > calls C3 to print some result on some kind of output device.

            You conflate two issues there. One is the domino theory, C1 -> C2 -> C3.

            The other is the proton problem. C3 affects hardware.

            (For my second TDD project ever, I once solved the proton problem by
            configuring my tests to pick a random fax machine in our office and
            send a bunch of faxes to it. Each time I hit the test button I
            destroyed the environment, and filled our office up with faxes that
            said "test data" at the top.)

            > to test
            > C1, real implemention of C2 has to already exist, the same applies to
            > C3. and, more important, to check the C1's behavior, i have to
            > finally check the C3's output, in many cases, i find it is teadious
            > and impossible.

            TDD tests generate behavior, not structure. The behavior in C3 could
            begin life in C1 and then migrate to C3. The tests still cover, and
            new tests should go to C2 or C3. Sometimes you set them up with a mock
            and sometimes you don't.

            To avoid polluting your regional protons, mock early and often. I
            fixed my fax tests by subscribing to a free online fax service. It
            e-mailed GIFs back to me.

            Then I left the tests running in a loop one night, and when I came to
            work the site had kill-filed me.

            --
            Phlip
            http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
          • John A. De Goes
            ... Let s go all the way back to the beginning. You need a feature to print a report. So you sketch some class C1 with a method to print a report, and write a
            Message 5 of 29 , Dec 1, 2006
            • 0 Attachment
              Quoting Steven Woody <narkewoody@...>:
              > it's interesting, but ... the problem is how to write decoupled code
              > with few needs of object mocking. supposing i have three classes, C1,
              > C2 and C3. a method of C1 uses a method of C2 and the method of C2
              > calls C3 to print some result on some kind of output device.

              Let's go all the way back to the beginning.

              You need a feature to print a report. So you sketch some class C1 with
              a method to print a report, and write a failing testcase for it. Now
              you implement the method in straightforward fashion by hard-coding
              printline statements.

              Sometime later, you learn you need to be able to print to HTML, in
              addition to standard out. Since HTML is a structured format, you
              create an interface, say C2, which contains a set of structured print
              methods, and you TDD delegation to a standard out implementation of C2
              that just uses spaces to represent structural information.

              This little refactoring enables you to TDD another implementation of
              C2 that 'prints' to HTML. At this point, C1, and both implementations
              of C2, have their own set of tests; and the tests for C1 indirectly
              test both implementations of C2. This is good -- it provides natural
              redundancy and is common in TDD'd code that doesn't use mock objects.

              Soon after you learn the customer wants to be able to perform
              structural translations on the fly (altering importance or ordering of
              headings, for example). You write your failing testcases, and stuff
              the restructuring code into both implementations of C2 in order to see
              the green.

              Now it's time for cleanup. You factor out the common restructuring
              code into a new class, say T, which then delegates to one of the two
              implementations of C2. You then rename C2 to C3, and T to C2.

              Now you have C1, C2, and C3. C1 calls to C2, which in turn calls to
              some implementation of C3, which ultimately prints out the
              information, to either standard out or HTML, depending on the
              implementation.

              Exactly the situation you describe. No need for mock objects, thank
              you. Each class is tested directly, and all of them are tested
              together (at the level of the tests for C1), which is often why TDDers
              refuse to call their tests 'unit tests' -- they can easily span huge
              chunks of the application.

              Regards,

              John
            • Keith Ray
              ... In other words you should TDD the class C , and then refactor class C into classes C1 , C2 , and C3 . No mocks necessary until you get to the point
              Message 6 of 29 , Dec 1, 2006
              • 0 Attachment
                > You conflate two issues there. One is the domino theory, C1 -> C2 -> C3.

                In other words you should TDD the class "C", and then refactor class
                "C" into classes "C1", "C2", and "C3". No mocks necessary until you
                get to the point where you need to avoid messing with physical
                hardware.


                ----
                I n d u s t r i a l L o g i c , I n c .
                C. Keith Ray
                http://industriallogic.com
                http://industrialxp.org
                866-540-8336 (toll free)
                510-540-8336 (phone)
                Berkeley, California
              • Steven Woody
                ... thank you very much, i begin to understan. but i still want to question: how about working with other members in a team? here, you can image C1, C2, C3
                Message 7 of 29 , Dec 1, 2006
                • 0 Attachment
                  On 12/2/06, John A. De Goes <john@...> wrote:
                  >
                  >
                  >
                  >
                  >
                  >
                  > Quoting Steven Woody <narkewoody@...>:
                  > > it's interesting, but ... the problem is how to write decoupled code
                  > > with few needs of object mocking. supposing i have three classes, C1,
                  > > C2 and C3. a method of C1 uses a method of C2 and the method of C2
                  > > calls C3 to print some result on some kind of output device.
                  >
                  > Let's go all the way back to the beginning.
                  >
                  > You need a feature to print a report. So you sketch some class C1 with
                  > a method to print a report, and write a failing testcase for it. Now
                  > you implement the method in straightforward fashion by hard-coding
                  > printline statements.
                  >
                  > Sometime later, you learn you need to be able to print to HTML, in
                  > addition to standard out. Since HTML is a structured format, you
                  > create an interface, say C2, which contains a set of structured print
                  > methods, and you TDD delegation to a standard out implementation of C2
                  > that just uses spaces to represent structural information.
                  >
                  > This little refactoring enables you to TDD another implementation of
                  > C2 that 'prints' to HTML. At this point, C1, and both implementations
                  > of C2, have their own set of tests; and the tests for C1 indirectly
                  > test both implementations of C2. This is good -- it provides natural
                  > redundancy and is common in TDD'd code that doesn't use mock objects.
                  >
                  > Soon after you learn the customer wants to be able to perform
                  > structural translations on the fly (altering importance or ordering of
                  > headings, for example). You write your failing testcases, and stuff
                  > the restructuring code into both implementations of C2 in order to see
                  > the green.
                  >
                  > Now it's time for cleanup. You factor out the common restructuring
                  > code into a new class, say T, which then delegates to one of the two
                  > implementations of C2. You then rename C2 to C3, and T to C2.
                  >
                  > Now you have C1, C2, and C3. C1 calls to C2, which in turn calls to
                  > some implementation of C3, which ultimately prints out the
                  > information, to either standard out or HTML, depending on the
                  > implementation.
                  >
                  > Exactly the situation you describe. No need for mock objects, thank
                  > you. Each class is tested directly, and all of them are tested
                  > together (at the level of the tests for C1), which is often why TDDers
                  > refuse to call their tests 'unit tests' -- they can easily span huge
                  > chunks of the application.
                  >

                  thank you very much, i begin to understan. but i still want to
                  question: how about working with other members in a team? here, you
                  can image C1, C2, C3 are not simple classses, they are actually
                  subsystem consisting many of classes to do a meanful job. we do a
                  rough front-design and have Tom to implement C1, and Jack to implement
                  C2 which will support the implementation of the C1. you see the
                  problem? if i don't want Tom to wail until Jack checkin a workable
                  version, i guess i will have to use mock, and if i won't, another
                  problem is every Tom's test will bother Jack. am i right? and how you
                  guys cure this kind of problem?

                  thanks.

                  -
                  woody
                • Bill Caputo
                  ... On my team here s how it goes: First, we pair together. If I am Tom, I pair with Jack on C2 until we have enough to start C1, then we switch and go work on
                  Message 8 of 29 , Dec 1, 2006
                  • 0 Attachment
                    On 12/1/06, Steven Woody <narkewoody@...> wrote:
                    > thank you very much, i begin to understan. but i still want to
                    > question: how about working with other members in a team? here, you
                    > can image C1, C2, C3 are not simple classses, they are actually
                    > subsystem consisting many of classes to do a meanful job. we do a
                    > rough front-design and have Tom to implement C1, and Jack to implement
                    > C2 which will support the implementation of the C1. you see the
                    > problem? if i don't want Tom to wail until Jack checkin a workable
                    > version, i guess i will have to use mock, and if i won't, another
                    > problem is every Tom's test will bother Jack. am i right? and how you
                    > guys cure this kind of problem?

                    On my team here's how it goes: First, we pair together. If I am Tom, I
                    pair with Jack on C2 until we have enough to start C1, then we switch
                    and go work on C1 for a while (or perhaps I pair with Jane on C1 while
                    Jack pairs with Joe to continue C2). In either case, we spend about 3
                    hours working on things (test-code-refactor), then check-in, switch
                    pairs and/or tasks, and repeat. We are also working in easy talking
                    distance of each other, so that if we need to collaborate further, we
                    just do so.

                    As for the subsystem part -- we don't sign up for subsystems -- or
                    even classes, we take tasks (think 3 hours to 2 days max to implement
                    something that furthers a story) and we switch up in 1/2 day
                    increments. If all of its done test-first, it doesn't matter anyway,
                    you'll extend what's there in small increments regardless.

                    In short: the application of small tasks, pairing, frequent pair
                    switching, pairing across tasks, co-location, and test-code-refactor
                    are sufficient to tackle this scenario... regardless of language.

                    Best,
                    Bill
                  • Ron Jeffries
                    Hello, Steven. On Saturday, December 2, 2006, at 12:29:57 AM, you ... You have correctly identified that dividing the work between people by class doesn t
                    Message 9 of 29 , Dec 2, 2006
                    • 0 Attachment
                      Hello, Steven. On Saturday, December 2, 2006, at 12:29:57 AM, you
                      wrote:

                      > thank you very much, i begin to understan. but i still want to
                      > question: how about working with other members in a team? here, you
                      > can image C1, C2, C3 are not simple classses, they are actually
                      > subsystem consisting many of classes to do a meanful job. we do a
                      > rough front-design and have Tom to implement C1, and Jack to implement
                      > C2 which will support the implementation of the C1. you see the
                      > problem? if i don't want Tom to wail until Jack checkin a workable
                      > version, i guess i will have to use mock, and if i won't, another
                      > problem is every Tom's test will bother Jack. am i right? and how you
                      > guys cure this kind of problem?

                      You have correctly identified that dividing the work between people
                      by class doesn't work.

                      One good solution is ... don't do that.

                      XP has practices like Pair Programming and Team Code Ownership to
                      address that ...

                      Ron Jeffries
                      www.XProgramming.com
                      Perhaps this Silver Bullet will tell you who I am ...
                    • Steven Woody
                      ... thank you. is there any book dedicately contribute to Pair Programming and Team Code Ownership? - woody
                      Message 10 of 29 , Dec 2, 2006
                      • 0 Attachment
                        On 12/2/06, Ron Jeffries <ronjeffries@...> wrote:
                        >
                        >
                        >
                        >
                        >
                        >
                        > Hello, Steven. On Saturday, December 2, 2006, at 12:29:57 AM, you
                        > wrote:
                        >
                        > > thank you very much, i begin to understan. but i still want to
                        > > question: how about working with other members in a team? here, you
                        > > can image C1, C2, C3 are not simple classses, they are actually
                        > > subsystem consisting many of classes to do a meanful job. we do a
                        > > rough front-design and have Tom to implement C1, and Jack to implement
                        > > C2 which will support the implementation of the C1. you see the
                        > > problem? if i don't want Tom to wail until Jack checkin a workable
                        > > version, i guess i will have to use mock, and if i won't, another
                        > > problem is every Tom's test will bother Jack. am i right? and how you
                        > > guys cure this kind of problem?
                        >
                        > You have correctly identified that dividing the work between people
                        > by class doesn't work.
                        >
                        > One good solution is ... don't do that.
                        >
                        > XP has practices like Pair Programming and Team Code Ownership to
                        > address that ...
                        >

                        thank you. is there any book dedicately contribute to Pair
                        Programming and Team Code Ownership?

                        -
                        woody
                      • Keith Ray
                        Pair Programming Illuminated is the book on pair programming. Collaboration Explained is another book, which is on my to-read list. There are a few more
                        Message 11 of 29 , Dec 2, 2006
                        • 0 Attachment
                          "Pair Programming Illuminated" is the book on pair programming.

                          "Collaboration Explained" is another book, which is on my to-read list.

                          There are a few more here:

                          http://homepage.mac.com/keithray/xpminifaq.html

                          On 12/2/06, Steven Woody <narkewoody@...> wrote:
                          > On 12/2/06, Ron Jeffries <ronjeffries@...> wrote:
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > > Hello, Steven. On Saturday, December 2, 2006, at 12:29:57 AM, you
                          > > wrote:
                          > >
                          > > > thank you very much, i begin to understan. but i still want to
                          > > > question: how about working with other members in a team? here, you
                          > > > can image C1, C2, C3 are not simple classses, they are actually
                          > > > subsystem consisting many of classes to do a meanful job. we do a
                          > > > rough front-design and have Tom to implement C1, and Jack to implement
                          > > > C2 which will support the implementation of the C1. you see the
                          > > > problem? if i don't want Tom to wail until Jack checkin a workable
                          > > > version, i guess i will have to use mock, and if i won't, another
                          > > > problem is every Tom's test will bother Jack. am i right? and how you
                          > > > guys cure this kind of problem?
                          > >
                          > > You have correctly identified that dividing the work between people
                          > > by class doesn't work.
                          > >
                          > > One good solution is ... don't do that.
                          > >
                          > > XP has practices like Pair Programming and Team Code Ownership to
                          > > address that ...
                          > >
                          >
                          > thank you. is there any book dedicately contribute to Pair
                          > Programming and Team Code Ownership?
                          >
                          > -
                          > woody

                          ----
                          C. Keith Ray
                        • John A. De Goes
                          Hi Steven, ... I see you re trying to concurrently implement a collection of subsystems that depend on each other, based on an initial design. The problem with
                          Message 12 of 29 , Dec 2, 2006
                          • 0 Attachment
                            Hi Steven,

                            > thank you very much, i begin to understan. but i still want to
                            > question: how about working with other members in a team? here,
                            > you can image C1, C2, C3 are not simple classses, they are actually
                            > subsystem consisting many of classes to do a meanful job. we do a
                            > rough front-design and have Tom to implement C1, and Jack to
                            > implement C2 which will support the implementation of the C1. you
                            > see the problem?

                            I see you're trying to concurrently implement a collection of subsystems that depend on each other, based on an initial design. The problem with this approach is one of waste:

                            1. Your initial design is going to have some features it doesn't need;

                            2. Because you can't anticipate everything you *will* need, some features you forgot will probably not fit into your architecture, and will force you to do substantial architectural revisions;

                            3. Different teams will have different ideas about how the interfaces between the subsystems are supposed to operate, resulting in incompatibilities that need to be smoothed over;

                            4. The design is constrained to fit your initial model, and while it may be possible to solve the problem in a way that fits the model, it may not be the most efficient way of solving the problem.

                            One way to reduce waste, and avoid mock objects, is to practice 'vertical slice development.' In this approach, instead of coding individual subsystems (concurrently or sequentially), which you then try to glue together at the end, you divide the problem into 'features', each of which has some value to the 'customer'.

                            The features generally cut through multiple subsystems. Team A takes feature 1, Team B takes feature 2, and Team C takes feature 3. If everyone is practicing continuous integration, checking their code in every few hours, then coherent subsystems will form naturally, through the process of refactoring.

                            Regards,

                            John
                          • Phlip
                            ... Shorter way to say it: Developers own features, not classes. You pull the card for a feature, you get a pair, you change here and there to implement the
                            Message 13 of 29 , Dec 2, 2006
                            • 0 Attachment
                              Ron Jeffries wrote:

                              > You have correctly identified that dividing the work between people
                              > by class doesn't work.
                              >
                              > One good solution is ... don't do that.
                              >
                              > XP has practices like Pair Programming and Team Code Ownership to
                              > address that ...

                              Shorter way to say it:

                              Developers own features, not classes.

                              You pull the card for a feature, you get a pair, you change here and there
                              to implement the feature, and you check in.

                              --
                              Phlip
                              http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                            • Steven Woody
                              ... thank you John. if i still has something to ask on this subject, i think that is what is the essential difference between feature and tasks. can you show
                              Message 14 of 29 , Dec 3, 2006
                              • 0 Attachment
                                On 12/3/06, John A. De Goes <john@...> wrote:
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                > Hi Steven,
                                >
                                > > thank you very much, i begin to understan. but i still want to
                                > > question: how about working with other members in a team? here,
                                > > you can image C1, C2, C3 are not simple classses, they are actually
                                > > subsystem consisting many of classes to do a meanful job. we do a
                                > > rough front-design and have Tom to implement C1, and Jack to
                                > > implement C2 which will support the implementation of the C1. you
                                > > see the problem?
                                >
                                > I see you're trying to concurrently implement a collection of subsystems that depend on each other, based on an initial design. The problem with this approach is one of waste:
                                >
                                > 1. Your initial design is going to have some features it doesn't need;
                                >
                                > 2. Because you can't anticipate everything you *will* need, some features you forgot will probably not fit into your architecture, and will force you to do substantial architectural revisions;
                                >
                                > 3. Different teams will have different ideas about how the interfaces between the subsystems are supposed to operate, resulting in incompatibilities that need to be smoothed over;
                                >
                                > 4. The design is constrained to fit your initial model, and while it may be possible to solve the problem in a way that fits the model, it may not be the most efficient way of solving the problem.
                                >
                                > One way to reduce waste, and avoid mock objects, is to practice 'vertical slice development.' In this approach, instead of coding individual subsystems (concurrently or sequentially), which you then try to glue together at the end, you divide the problem into 'features', each of which has some value to the 'customer'.
                                >
                                > The features generally cut through multiple subsystems. Team A takes feature 1, Team B takes feature 2, and Team C takes feature 3. If everyone is practicing continuous integration, checking their code in every few hours, then coherent subsystems will form naturally, through the process of refactoring.
                                >
                                > Regards,
                                >
                                > John
                                >

                                thank you John. if i still has something to ask on this subject, i
                                think that is what is the essential difference between feature and
                                tasks. can you show some examples?

                                thank you.

                                -
                                woody
                              • Ron Jeffries
                                Hello, Phlip. On Sunday, December 3, 2006, at 1:32:54 AM, you ... While I do personally prefer the developer owns feature pattern , as far as I know, that s
                                Message 15 of 29 , Dec 3, 2006
                                • 0 Attachment
                                  Hello, Phlip. On Sunday, December 3, 2006, at 1:32:54 AM, you
                                  wrote:

                                  >> You have correctly identified that dividing the work between people
                                  >> by class doesn't work.
                                  >>
                                  >> One good solution is ... don't do that.
                                  >>
                                  >> XP has practices like Pair Programming and Team Code Ownership to
                                  >> address that ...

                                  > Shorter way to say it:

                                  > Developers own features, not classes.

                                  > You pull the card for a feature, you get a pair, you change here and there
                                  > to implement the feature, and you check in.

                                  While I do personally prefer the developer owns feature "pattern",
                                  as far as I know, that's not the only "XP" way to do it.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  A lot of preconceptions can be dismissed when you actually
                                  try something out. -- Bruce Eckel
                                • Phlip
                                  ... Yet it s the inverse way to say developers don t own classes , an ideal which XP supports. -- Phlip http://www.greencheese.us/ZeekLand
                                  Message 16 of 29 , Dec 3, 2006
                                  • 0 Attachment
                                    Ron Jeffries wrote:

                                    >> Developers own features, not classes.
                                    >
                                    > While I do personally prefer the developer owns feature "pattern",
                                    > as far as I know, that's not the only "XP" way to do it.

                                    Yet it's the inverse way to say "developers don't own classes", an ideal
                                    which XP supports.

                                    --
                                    Phlip
                                    http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                                  • Ron Jeffries
                                    Hello, Phlip. On Sunday, December 3, 2006, at 9:51:41 AM, you ... I believe that it might be that XP supports the notion that an individual developer
                                    Message 17 of 29 , Dec 3, 2006
                                    • 0 Attachment
                                      Hello, Phlip. On Sunday, December 3, 2006, at 9:51:41 AM, you
                                      wrote:

                                      > Ron Jeffries wrote:

                                      >>> Developers own features, not classes.
                                      >>
                                      >> While I do personally prefer the developer owns feature "pattern",
                                      >> as far as I know, that's not the only "XP" way to do it.

                                      > Yet it's the inverse way to say "developers don't own classes", an ideal
                                      > which XP supports.

                                      I believe that it might be that XP "supports" the notion that an
                                      individual developer generally does not "own" specific parts of the
                                      code.

                                      That does not imply that the developer therefore owns features, and
                                      I see no inverse relationship or other equivalence between "don't
                                      own classes" and "do own features".

                                      Ron Jeffries
                                      www.XProgramming.com
                                      No one expects the Spanish Inquisition ...
                                    • Phlip
                                      ... Developers own one user story during one iteration... -- Phlip http://www.greencheese.us/ZeekLand
                                      Message 18 of 29 , Dec 3, 2006
                                      • 0 Attachment
                                        Ron Jeffries wrote:

                                        > That does not imply that the developer therefore owns features

                                        Developers own one user story during one iteration...

                                        --
                                        Phlip
                                        http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                                      • Ron Jeffries
                                        Hello, Phlip. On Sunday, December 3, 2006, at 10:33:15 AM, you ... Not necessarily. That was, I believe, my original point. While I do think that is /a/ good
                                        Message 19 of 29 , Dec 3, 2006
                                        • 0 Attachment
                                          Hello, Phlip. On Sunday, December 3, 2006, at 10:33:15 AM, you
                                          wrote:

                                          > Ron Jeffries wrote:

                                          >> That does not imply that the developer therefore owns features

                                          > Developers own one user story during one iteration...

                                          Not necessarily. That was, I believe, my original point. While I do
                                          think that is /a/ good way, I don't think it is the only acceptable
                                          XP way.

                                          Take Arlo Belshee, for example.

                                          Ron Jeffries
                                          www.XProgramming.com
                                          Assume that anything you didn't like was the funny stuff.
                                          -- Jim Shore
                                        • Phlip
                                          ... If Mr Q pencil the estimate on a story card, I check with him, or his next-of-kin at least, before yanking it off the board and doing it. Right?? -- Phlip
                                          Message 20 of 29 , Dec 3, 2006
                                          • 0 Attachment
                                            Ron Jeffries wrote:

                                            >> Developers own one user story during one iteration...
                                            >
                                            > Not necessarily. That was, I believe, my original point. While I do
                                            > think that is /a/ good way, I don't think it is the only acceptable
                                            > XP way.

                                            If Mr Q pencil the estimate on a story card, I check with him, or his
                                            next-of-kin at least, before yanking it off the board and doing it. Right??

                                            --
                                            Phlip
                                            http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                                          • John A. De Goes
                                            Hi Steven, ... A feature is something that the customer wants. When a feature is implemented, the customer will be able to discern it. Generally, a feature is
                                            Message 21 of 29 , Dec 3, 2006
                                            • 0 Attachment
                                              Hi Steven,

                                              > thank you John. if i still has something to ask on this subject, i
                                              > think that is what is the essential difference between feature and
                                              > tasks. can you show some examples?

                                              A feature is something that the customer wants. When a feature is implemented, the customer will be able to discern it. Generally, a feature is something the customer can use, see, hear, touch, or feel (depending on the context).

                                              In a word processor, one feature might be the ability to italicize text in the document. In an interface for a digital camera, a feature might be the ability to change the number of frames per second. In an SDK targeted at programmers, a feature might be the ability to register a callback that's notified of state changes.

                                              Features are distinguished by the fact that they have value to the customer. Customers can look at them and say, 'Yeah, that feature moved the program closer to my goal.'

                                              In order to implement a feature, a programmer has to go through a number of tasks. These tasks are not generally visible to the user, and it's not obvious to the user that the program is any closer to her goal, when some task or another has been completed.

                                              Are the developers generally assigned 'tasks' at your company?

                                              Regards,

                                              John
                                            • Ron Jeffries
                                              Hello, Phlip. On Sunday, December 3, 2006, at 11:38:54 AM, you ... Yes, I think working together on things is a really good idea ... Ron Jeffries
                                              Message 22 of 29 , Dec 3, 2006
                                              • 0 Attachment
                                                Hello, Phlip. On Sunday, December 3, 2006, at 11:38:54 AM, you
                                                wrote:

                                                >>> Developers own one user story during one iteration...
                                                >>
                                                >> Not necessarily. That was, I believe, my original point. While I do
                                                >> think that is /a/ good way, I don't think it is the only acceptable
                                                >> XP way.

                                                > If Mr Q pencil the estimate on a story card, I check with him, or his
                                                > next-of-kin at least, before yanking it off the board and doing it. Right??

                                                Yes, I think working together on things is a really good idea ...

                                                Ron Jeffries
                                                www.XProgramming.com
                                                Any errors you find in this are the work of Secret Villains,
                                                whose mad schemes will soon be revealed. -- Wil McCarthy
                                              • Phlip
                                                ... Okay. Mr Q, our database guy , wrote a 10 minute estimate on the card. I, who know least about the database, will pull it and go pair with Mr. Spalding,
                                                Message 23 of 29 , Dec 3, 2006
                                                • 0 Attachment
                                                  Ron Jeffries wrote:

                                                  >> If Mr Q pencil the estimate on a story card, I check with him, or his
                                                  >> next-of-kin at least, before yanking it off the board and doing it.
                                                  >> Right??
                                                  >
                                                  > Yes, I think working together on things is a really good idea ...

                                                  Okay. Mr Q, our "database guy", wrote a 10 minute estimate on the card. I,
                                                  who know least about the database, will pull it and go pair with Mr.
                                                  Spalding, who knows the second-least.

                                                  A-working-together we go!

                                                  --
                                                  Phlip
                                                  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                                                • Adrian Sutton
                                                  ... This is a very good thing. By the time you have done your task you will both know more about the database and be more productive, valuable members of the
                                                  Message 24 of 29 , Dec 3, 2006
                                                  • 0 Attachment
                                                    On 04/12/2006, at 5:45 AM, Phlip wrote:
                                                    > Okay. Mr Q, our "database guy", wrote a 10 minute estimate on the
                                                    > card. I,
                                                    > who know least about the database, will pull it and go pair with Mr.
                                                    > Spalding, who knows the second-least.
                                                    >
                                                    > A-working-together we go!

                                                    This is a very good thing. By the time you have done your task you
                                                    will both know more about the database and be more productive,
                                                    valuable members of the team in future. The team bus number has now
                                                    been increased.

                                                    If along the way you need help, you'll ask for it because everyone in
                                                    your team is happy to offer assistance and their close by because you
                                                    all sit together. The worst possible outcome is that the task you're
                                                    implementing is such a mess it needs to be thrown out and started
                                                    again, but you can't possibly break anything that's already working
                                                    because the tests will tell you about it before you check in.

                                                    If any of the above isn't true in your team then you have a problem,
                                                    but it doesn't lie in who is taking on the task. One thing I can see
                                                    as a problem is that you have individual developers estimating tasks
                                                    rather than the team as a whole. While this is tempting to speed up
                                                    the estimating process, it means that the person who estimated the
                                                    task is likely the only person for whom the estimate is valid. If
                                                    they happen to be sick for a few days, or busy with something else,
                                                    you're in trouble.

                                                    At least, that's the way I see it. It's not easy to get to that
                                                    stage, but I do see it as a very worthwhile goal.

                                                    Regards,

                                                    Adrian Sutton
                                                    http://www.symphonious.net
                                                  • Phlip
                                                    ... I hope you remember this mail when, someday, we are working together, and you pencil a 1-day estimate on a card, and then when you are out I grab it and a
                                                    Message 25 of 29 , Dec 3, 2006
                                                    • 0 Attachment
                                                      Adrian Sutton wrote:

                                                      > This is a very good thing. By the time you have done your task you
                                                      > will both know more about the database and be more productive,
                                                      > valuable members of the team in future. The team bus number has now
                                                      > been increased.

                                                      I hope you remember this mail when, someday, we are working together, and
                                                      you pencil a 1-day estimate on a card, and then when you are out I grab it
                                                      and a pair and spend 3 days doing it very badly.

                                                      --
                                                      Phlip
                                                      http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                                                    • Russel Hill
                                                      ... But, ... did you learn something in the process? Badly written code that has supporting tests can usually be dealt with. Possibly when the senior team
                                                      Message 26 of 29 , Dec 3, 2006
                                                      • 0 Attachment
                                                        On 12/3/06, Phlip <phlip2005@...> wrote:
                                                        > > This is a very good thing. By the time you have done your task you
                                                        > > will both know more about the database and be more productive,
                                                        > > valuable members of the team in future. The team bus number has now
                                                        > > been increased.
                                                        >
                                                        > I hope you remember this mail when, someday, we are working together, and
                                                        > you pencil a 1-day estimate on a card, and then when you are out I grab it
                                                        > and a pair and spend 3 days doing it very badly.

                                                        But, ... did you learn something in the process?

                                                        Badly written code that has supporting tests can usually be dealt
                                                        with. Possibly when the senior team member returns the less
                                                        experienced team member(s) will get to pair on the cleanup. I have
                                                        occasionally allowed inexperienced pairs to go it alone for a few days
                                                        just to experience this. I think this helps them refine their skills
                                                        and develop a nose for smelly code.
                                                      • Adrian Sutton
                                                        ... Ah but you wouldn t, because you d come and ask for help once you realize you are struggling. Alternatively, you d mention you were working on it at the
                                                        Message 27 of 29 , Dec 3, 2006
                                                        • 0 Attachment
                                                          On 04/12/2006, at 8:13 AM, Phlip wrote:

                                                          > Adrian Sutton wrote:
                                                          >
                                                          >> This is a very good thing. By the time you have done your task you
                                                          >> will both know more about the database and be more productive,
                                                          >> valuable members of the team in future. The team bus number has now
                                                          >> been increased.
                                                          >
                                                          > I hope you remember this mail when, someday, we are working
                                                          > together, and
                                                          > you pencil a 1-day estimate on a card, and then when you are out I
                                                          > grab it
                                                          > and a pair and spend 3 days doing it very badly.

                                                          Ah but you wouldn't, because you'd come and ask for help once you
                                                          realize you are struggling. Alternatively, you'd mention you were
                                                          working on it at the next morning's stand up and I'd check in to see
                                                          how you're going. This is actually quite similar to my current
                                                          situation - I have more experience with the code base than anyone and
                                                          so I spend a lot of my time helping bring others up to speed when
                                                          they are venturing into areas they don't know much about yet.

                                                          Yes the work would get done faster if I did it myself, but that's
                                                          only a short term view. Even if I take up all my time helping the
                                                          five other team members to be more productive and learn more about
                                                          the code, the team as a whole will go faster than if I took on
                                                          everything myself and left them to struggle without assistance.

                                                          The key to making it works comes in the discussion that started off
                                                          this tangent:

                                                          >>> That does not imply that the developer therefore owns feature
                                                          >
                                                          >> Developers own one user story during one iteration...
                                                          >
                                                          > Not necessarily. That was, I believe, my original point. While I do
                                                          > think that is /a/ good way, I don't think it is the only acceptable
                                                          > XP way.

                                                          If you have developers that own a story, feature, task or class, they
                                                          can get themselves lost and struggle and the team won't be there to
                                                          help out. If the *team* owns all the stories, tasks, features and
                                                          classes then we all work together to make sure that everything gets
                                                          down. It can be useful for one person to take ownership of tracking
                                                          the progress of a story to make sure it doesn't fall between the
                                                          cracks, but the team as a whole is still responsible for doing the
                                                          work. Sharing the work load and responsibility also means sharing the
                                                          knowledge, so when someone in the team is struggling they can ask for
                                                          help or other team members will just notice they are struggling and
                                                          go and help.

                                                          My experience is that it works very well, but you do need a well
                                                          gelled team.

                                                          Regards,

                                                          Adrian Sutton
                                                          http://www.symphonious.net
                                                        • Ilja Preuss
                                                          ... I think you misunderstood what working together means. Take care, Ilja
                                                          Message 28 of 29 , Dec 3, 2006
                                                          • 0 Attachment
                                                            Phlip schrieb:
                                                            > Adrian Sutton wrote:
                                                            >
                                                            >> This is a very good thing. By the time you have done your task you
                                                            >> will both know more about the database and be more productive,
                                                            >> valuable members of the team in future. The team bus number has now
                                                            >> been increased.
                                                            >
                                                            > I hope you remember this mail when, someday, we are working together, and
                                                            > you pencil a 1-day estimate on a card, and then when you are out I grab it
                                                            > and a pair and spend 3 days doing it very badly.

                                                            I think you misunderstood what "working together" means.

                                                            Take care, Ilja
                                                          • Ron Jeffries
                                                            Hello, Phlip. On Sunday, December 3, 2006, at 5:13:54 PM, you ... Even if you accepted the estimate blindly, wouldn t you be wise enough, at the end of the
                                                            Message 29 of 29 , Dec 3, 2006
                                                            • 0 Attachment
                                                              Hello, Phlip. On Sunday, December 3, 2006, at 5:13:54 PM, you
                                                              wrote:

                                                              > Adrian Sutton wrote:

                                                              >> This is a very good thing. By the time you have done your task you
                                                              >> will both know more about the database and be more productive,
                                                              >> valuable members of the team in future. The team bus number has now
                                                              >> been increased.

                                                              > I hope you remember this mail when, someday, we are working together, and
                                                              > you pencil a 1-day estimate on a card, and then when you are out I grab it
                                                              > and a pair and spend 3 days doing it very badly.

                                                              Even if you accepted the estimate blindly, wouldn't you be wise
                                                              enough, at the end of the first day (if not the first morning) to
                                                              mention at the standup that you were in trouble?

                                                              Ron Jeffries
                                                              www.XProgramming.com
                                                              Testing quality into a program is like spinning straw into gold.
                                                              -- George Cameron.
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.