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

Re: How do I defy "I will eventually write a test" statement

Expand Messages
  • mfeathers256
    ... Ask them how much they are willing to wager that they ll have N% coverage at the end of two weeks. Put a monetary value on it. If they hesitate, ask them
    Message 1 of 17 , Dec 6, 2007
    View Source
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Pat Maddox" <pergesu@...>
      wrote:
      >
      > On Dec 5, 2007 5:41 PM, Andrew H. Chen <andrewhangchen@...> wrote:
      > > I lately come to one project with is doing fake agile.
      > >
      > > How do I reason with this?
      > >
      > >
      > > "I will write code first, then I will write unit test next week.
      > >
      > > So at the end of 2 weeks, I will have both code and unit test codes."
      > >
      > >
      > > What's a simple and convincing way to defy the above statement?
      >
      > I like to run the unit test suite and then start deleting code until a
      > test fails. Bonus points if you can wipe their repo so they can't
      > recover.
      >
      > Pat
      >

      Ask them how much they are willing to wager that they'll have N%
      coverage at the end of two weeks. Put a monetary value on it. If
      they hesitate, ask them why.
    • Kent Beck
      Dear Andrew, It sounds like the other person in the conversation has some idea of agility, at least as far as taking responsibility for the quality of his
      Message 2 of 17 , Dec 6, 2007
      View Source
      • 0 Attachment
        Dear Andrew,

        It sounds like the other person in the conversation has some idea of
        agility, at least as far as taking responsibility for the quality of his
        code. He might be practicing "fake agile" from your perspective, but a
        person or team that really executed on his strategy would likely be more
        effective than the many teams that let someone else do most of the testing
        later.

        I wonder what an appreciative approach would yield in this case. Rather than
        defy him, you could ask him to talk about the best tested code he had ever
        worked on, then explore the factors that went into creating that situation.
        Finish by asking him to apply the lessons of his story to his current
        development. (For more on this see "Appreciating Your Way to XP" on
        www.threeriversinstitute.org or "The Thin Book of Appreciative Inquiry".)

        My experience is that engaging people to talk about their positive
        experiences helps create relationships, produces workable ideas that people
        are convinced about, and sets up future improvement. What is missing for me
        is the sense that I am controlling what the other person is doing. I never
        really was in control of other people but I still miss the feeling sometimes
        :-)

        Regards,

        Kent Beck
        Three Rivers Institute

        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Andrew H. Chen
        Sent: Wednesday, December 05, 2007 5:42 PM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] How do I defy "I will eventually write a test" statement



        I lately come to one project with is doing fake agile.

        How do I reason with this?

        "I will write code first, then I will write unit test next week.

        So at the end of 2 weeks, I will have both code and unit test codes."

        What's a simple and convincing way to defy the above statement?

        Thanks
        ~Andrew Chen






        [Non-text portions of this message have been removed]
      • Matt
        Excellent perspective... thanks for pointing out the human element of software development! ;) ... his ... more ... testing ... Rather than ... ever ...
        Message 3 of 17 , Dec 6, 2007
        View Source
        • 0 Attachment
          Excellent perspective... thanks for pointing out the human element of
          software development! ;)



          --- In extremeprogramming@yahoogroups.com, "Kent Beck" <kentb@...>
          wrote:
          >
          > Dear Andrew,
          >
          > It sounds like the other person in the conversation has some idea of
          > agility, at least as far as taking responsibility for the quality of
          his
          > code. He might be practicing "fake agile" from your perspective, but a
          > person or team that really executed on his strategy would likely be
          more
          > effective than the many teams that let someone else do most of the
          testing
          > later.
          >
          > I wonder what an appreciative approach would yield in this case.
          Rather than
          > defy him, you could ask him to talk about the best tested code he had
          ever
          > worked on, then explore the factors that went into creating that
          situation.
          > Finish by asking him to apply the lessons of his story to his current
          > development. (For more on this see "Appreciating Your Way to XP" on
          > www.threeriversinstitute.org or "The Thin Book of Appreciative
          Inquiry".)
          >
          > My experience is that engaging people to talk about their positive
          > experiences helps create relationships, produces workable ideas that
          people
          > are convinced about, and sets up future improvement. What is missing
          for me
          > is the sense that I am controlling what the other person is doing. I
          never
          > really was in control of other people but I still miss the feeling
          sometimes
          > :-)
          >
          > Regards,
          >
          > Kent Beck
          > Three Rivers Institute
          >
        • George Dinwiddie
          ... I also wonder how much they have to modify the code to make it testable. - George -- ... * George Dinwiddie *
          Message 4 of 17 , Dec 6, 2007
          View Source
          • 0 Attachment
            Laurent Bossavit wrote:
            > Hi Andrew,
            >
            >> "I will write code first, then I will write unit test next week.
            >> So at the end of 2 weeks, I will have both code and unit test codes."
            >
            > Is the above what they *actually* do ? How good is their test
            > coverage ? How much time do they spend debugging ?

            I also wonder how much they have to modify the code to make it testable.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Arunraj, Edward
            Dear Kent, Thanks for the good article on Appreciative Inquiry & XP. My question is, how do create paradigm shifts with AI? Or is it possible at all? From my
            Message 5 of 17 , Dec 7, 2007
            View Source
            • 0 Attachment
              Dear Kent,

              Thanks for the good article on Appreciative Inquiry & XP.

              My question is, how do create paradigm shifts with AI? Or is it possible at all?

              From my experience of using AI and theoretically as well, AI is past anchored, in the positive way.
              It works well if I have had previous good experiences of my current situation.
              What if I have to see a new way, like for eg, Incr Arch, TDD. These are paradigm shifts for someone new to Agile.

              For example, what if,
              (a) Past success stories are based on BDUF, how do you use IA to lead the other person to considering Incr Arch.
              (b) There were situations where TDD-like actions led to better design but it is considered to be "expensive" and not taken forward.

              I think I won't be wrong if I say, Andrew needs to effect a paradigm shift in his colleague.


              Best Regards,

              Eddie.


              ________________________________
              From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Kent Beck
              Sent: 2007 Dec 06 8:43 PM
              To: extremeprogramming@yahoogroups.com
              Subject: RE: [XP] How do I defy "I will eventually write a test" statement


              Dear Andrew,

              It sounds like the other person in the conversation has some idea of
              agility, at least as far as taking responsibility for the quality of his
              code. He might be practicing "fake agile" from your perspective, but a
              person or team that really executed on his strategy would likely be more
              effective than the many teams that let someone else do most of the testing
              later.

              I wonder what an appreciative approach would yield in this case. Rather than
              defy him, you could ask him to talk about the best tested code he had ever
              worked on, then explore the factors that went into creating that situation.
              Finish by asking him to apply the lessons of his story to his current
              development. (For more on this see "Appreciating Your Way to XP" on
              www.threeriversinstitute.org or "The Thin Book of Appreciative Inquiry".)

              My experience is that engaging people to talk about their positive
              experiences helps create relationships, produces workable ideas that people
              are convinced about, and sets up future improvement. What is missing for me
              is the sense that I am controlling what the other person is doing. I never
              really was in control of other people but I still miss the feeling sometimes
              :-)

              Regards,

              Kent Beck
              Three Rivers Institute

              _____

              From: extremeprogramming@yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>
              [mailto:extremeprogramming@yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>] On Behalf Of Andrew H. Chen
              Sent: Wednesday, December 05, 2007 5:42 PM
              To: extremeprogramming@yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>
              Subject: [XP] How do I defy "I will eventually write a test" statement

              I lately come to one project with is doing fake agile.

              How do I reason with this?

              "I will write code first, then I will write unit test next week.

              So at the end of 2 weeks, I will have both code and unit test codes."

              What's a simple and convincing way to defy the above statement?

              Thanks
              ~Andrew Chen

              [Non-text portions of this message have been removed]



              [Non-text portions of this message have been removed]
            • Ron Jeffries
              Hello, Edward and Kent. I share Edward s question and have a guess at how one might answer based on my current thinking about creating ... I m very interested
              Message 6 of 17 , Dec 7, 2007
              View Source
              • 0 Attachment
                Hello, Edward and Kent. I share Edward's question and have a guess
                at how one might answer based on my current thinking about creating
                change. On Friday, December 7, 2007, at 6:21:51 AM, you wrote:

                > Dear Kent,

                > Thanks for the good article on Appreciative Inquiry & XP.
                > My question is, how do create paradigm shifts with AI? Or is it possible at all?

                I'm very interested in Kent's view on this. As for me ...

                I've come to think of what I do as showing people what I do,
                explaining why I do it, how I think about it, and telling them what
                I observe when other people do things in various ways.

                It is not my purpose to change them, but to inform them, give them
                options, give them ways to think about their work that they may find
                helpful.

                About the only actual advice I give is to select from all the ideas
                before them and actually try things before deciding.

                Now of course I do have a way of working that I prefer, and if I
                were doing software for my work, I'd work that way. So I do think
                that they "should" do some of the things I talk about. But it's
                their deal, they can do it or not.

                Were I a manager, I would bring about change in a somewhat different
                way. I think that Scrum has this almost right as a beginning. I'd
                ask for running tested features every month or less, and make it
                clear that I liked more features, running better, over fewer. This
                would, I am quite sure, provide people with an incentive to learn
                how to make me happy. No one likes me when I'm not happy. :)

                But even then I'd not really be doing it with a purpose of causing
                change. I'd be doing it because I could do my job of delivering
                software better if I had a visible flow of working features coming
                out. My purpose would be to do my job effectively and to enable my
                peeps to help me do that.

                Ron Jeffries
                www.XProgramming.com
                It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
              • Adam Dymitruk
                I went to see Josh Kerievsky speak a couple of days ago.. he provided some numbers. They can by found on this blog post:
                Message 7 of 17 , Dec 7, 2007
                View Source
                • 0 Attachment
                  I went to see Josh Kerievsky speak a couple of days ago.. he provided some
                  numbers. They can by found on this blog post:

                  http://adventuresinagile.blogspot.com/2007/12/joshua-kerievskys-10-terrific_06.html

                  Cheers,

                  Adam

                  On Dec 5, 2007 6:31 PM, Ron Jeffries <ronjeffries@...> wrote:

                  > Hello, Andrew. On Wednesday, December 5, 2007, at 5:41:37 PM, you
                  >
                  > wrote:
                  >
                  > > I lately come to one project with is doing fake agile.
                  >
                  > > How do I reason with this?
                  >
                  > > "I will write code first, then I will write unit test next week.
                  >
                  > > So at the end of 2 weeks, I will have both code and unit test codes."
                  >
                  > > What's a simple and convincing way to defy the above statement?
                  >
                  > Count the defects and time to implement stories done with real TDD
                  > and those done this way. Be guided by the numbers.
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > I'm giving the best advice I have. You get to decide whether it's true for
                  > you.
                  >
                  >
                  >

                  13141516


                  [Non-text portions of this message have been removed]
                • Joshua Kerievsky
                  ... Hello Adam -- thanks for attending the talk. Were you the fellow talking about mocks in .NET? As I mentioned that night, Five Core Metrics -- the book by
                  Message 8 of 17 , Dec 7, 2007
                  View Source
                  • 0 Attachment
                    Adam Dymitruk wrote:
                    > I went to see Josh Kerievsky speak a couple of days ago.. he provided some
                    > numbers. They can by found on this blog post:
                    >
                    > http://adventuresinagile.blogspot.com/2007/12/joshua-kerievskys-10-terrific_06.html
                    >
                    Hello Adam -- thanks for attending the talk. Were you the fellow
                    talking about mocks in .NET?

                    As I mentioned that night, Five Core Metrics -- the book by Lawrence H.
                    Putnam and Ware Myers -- is a story of how these pioneers and master
                    practitioners of the metrics world have come to think about and explain
                    metrics to the rest of us.

                    The numbers I cited came from analysis of real-world XP projects that
                    Industrial Logic has helped coach. The analysis was conducted by
                    Michael Mah -- who works with Mr. Putnam at QSM.

                    The folks at QSM have taught me that good, quantitative data is possible
                    to gather on XP/Agile projects. The secret is to stop trying to invent
                    new metrics and work with actual metrics experts.

                    --
                    best regards,
                    jk

                    I n d u s t r i a l L o g i c , I n c .
                    Joshua Kerievsky
                    Founder, Extreme Programmer & Coach
                    http://industriallogic.com
                    866-540-8336 (toll free)
                    510-540-8336 (phone)
                    Berkeley, California
                  • Kent Beck
                    Dear Eddie, The first thing I ve learned when applying Appreciative Inquiry is that mostly people already know what they need to know. My work is more
                    Message 9 of 17 , Dec 11, 2007
                    View Source
                    • 0 Attachment
                      Dear Eddie,

                      The first thing I've learned when applying Appreciative Inquiry is that
                      mostly people already know what they need to know. My work is more effective
                      if I remind them of things they have already done and help them see how to
                      apply it to their current work. I find this personally distressing as I
                      really like knowing esoteric stuff and teaching it to people, but my clients
                      don't seem to care about my distress :-)

                      However, in the rare case that a dramatic paradigm shift is really
                      necessary, I would still use AI, but ask people to draw on their
                      non-programming experiences for inspiration. A really effective sports team
                      or quilting circle or team of employees at a car wash could be a fertile
                      source of ideas for change.

                      If someone was asking me for help getting past BDUF, I might seed the
                      inquiry by asking them to describe the best design change they had ever made
                      to a running system. If they were asking for help with TDD, I'd ask them to
                      tell me a story about the best tested software they ever worked with. The
                      ideas they came up with might not be exactly incremental design or exactly
                      TDD, but they would likely be improvement and the other person would already
                      be convinced the ideas could work.

                      Regards,

                      Kent Beck
                      Three Rivers Institute

                      _____

                      From: extremeprogramming@yahoogroups.com
                      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Arunraj, Edward
                      Sent: Friday, December 07, 2007 6:22 AM
                      To: extremeprogramming@yahoogroups.com
                      Subject: RE: [XP] How do I defy "I will eventually write a test" statement



                      Dear Kent,

                      Thanks for the good article on Appreciative Inquiry & XP.

                      My question is, how do create paradigm shifts with AI? Or is it possible at
                      all?

                      From my experience of using AI and theoretically as well, AI is past
                      anchored, in the positive way.
                      It works well if I have had previous good experiences of my current
                      situation.
                      What if I have to see a new way, like for eg, Incr Arch, TDD. These are
                      paradigm shifts for someone new to Agile.

                      For example, what if,
                      (a) Past success stories are based on BDUF, how do you use IA to lead the
                      other person to considering Incr Arch.
                      (b) There were situations where TDD-like actions led to better design but it
                      is considered to be "expensive" and not taken forward.

                      I think I won't be wrong if I say, Andrew needs to effect a paradigm shift
                      in his colleague.

                      Best Regards,

                      Eddie.

                      ________________________________
                      From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                      yahoogroups.com [mailto:extremeprogramming@
                      <mailto:extremeprogramming%40yahoogroups.com> yahoogroups.com] On Behalf Of
                      Kent Beck
                      Sent: 2007 Dec 06 8:43 PM
                      To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                      yahoogroups.com
                      Subject: RE: [XP] How do I defy "I will eventually write a test" statement

                      Dear Andrew,

                      It sounds like the other person in the conversation has some idea of
                      agility, at least as far as taking responsibility for the quality of his
                      code. He might be practicing "fake agile" from your perspective, but a
                      person or team that really executed on his strategy would likely be more
                      effective than the many teams that let someone else do most of the testing
                      later.

                      I wonder what an appreciative approach would yield in this case. Rather than
                      defy him, you could ask him to talk about the best tested code he had ever
                      worked on, then explore the factors that went into creating that situation.
                      Finish by asking him to apply the lessons of his story to his current
                      development. (For more on this see "Appreciating Your Way to XP" on
                      www.threeriversinstitute.org or "The Thin Book of Appreciative Inquiry".)

                      My experience is that engaging people to talk about their positive
                      experiences helps create relationships, produces workable ideas that people
                      are convinced about, and sets up future improvement. What is missing for me
                      is the sense that I am controlling what the other person is doing. I never
                      really was in control of other people but I still miss the feeling sometimes
                      :-)

                      Regards,

                      Kent Beck
                      Three Rivers Institute

                      _____

                      From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                      yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>
                      [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                      yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>] On Behalf Of
                      Andrew H. Chen
                      Sent: Wednesday, December 05, 2007 5:42 PM
                      To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                      yahoogroups.com<mailto:extremeprogramming%40yahoogroups.com>
                      Subject: [XP] How do I defy "I will eventually write a test" statement

                      I lately come to one project with is doing fake agile.

                      How do I reason with this?

                      "I will write code first, then I will write unit test next week.

                      So at the end of 2 weeks, I will have both code and unit test codes."

                      What's a simple and convincing way to defy the above statement?

                      Thanks
                      ~Andrew Chen

                      [Non-text portions of this message have been removed]

                      [Non-text portions of this message have been removed]






                      [Non-text portions of this message have been removed]
                    • J. B. Rainsberger
                      ... I fielded this at XP/Agile Universe 2004. It seemed to work. Assume we write code and tests. There are at least 2 ways to go: 1. Write code, then test 2.
                      Message 10 of 17 , Dec 19, 2007
                      View Source
                      • 0 Attachment
                        On Dec 5, 2007, at 20:41 , Andrew H. Chen wrote:

                        > I lately come to one project with is doing fake agile.
                        >
                        > How do I reason with this?
                        >
                        > "I will write code first, then I will write unit test next week.
                        >
                        > So at the end of 2 weeks, I will have both code and unit test codes."
                        >
                        > What's a simple and convincing way to defy the above statement?
                        >
                        I fielded this at XP/Agile Universe 2004. It seemed to work.

                        Assume we write code and tests. There are at least 2 ways to go:

                        1. Write code, then test
                        2. Write test, then code

                        When it's easy to write the test, there's no real difference between
                        #1 and #2.

                        When it's hard to write the test, there is a tendency to want to re-
                        write the code to make the test simpler. If we don't have any code
                        yet, we don't have anything to re-write.

                        It can't get much simpler than that.
                        ----
                        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                        Your guide to software craftsmanship
                        JUnit Recipes: Practical Methods for Programmer Testing
                        2005 Gordon Pask Award for contribution Agile Software Practice
                      • Adam Dymitruk
                        Hi Joshua, Yes that was me! Hope to still get that clip of the monster method on the hotel lobby floor ... Adam ... [Non-text portions of this message have
                        Message 11 of 17 , Dec 19, 2007
                        View Source
                        • 0 Attachment
                          Hi Joshua,

                          Yes that was me!

                          Hope to still get that clip of the monster method on the hotel lobby floor
                          :0)

                          Adam

                          On 12/7/07, Joshua Kerievsky <joshua@...> wrote:
                          >
                          > Adam Dymitruk wrote:
                          > > I went to see Josh Kerievsky speak a couple of days ago.. he provided
                          > some
                          > > numbers. They can by found on this blog post:
                          > >
                          > >
                          > http://adventuresinagile.blogspot.com/2007/12/joshua-kerievskys-10-terrific_06.html
                          > >
                          > Hello Adam -- thanks for attending the talk. Were you the fellow
                          > talking about mocks in .NET?
                          >
                          > As I mentioned that night, Five Core Metrics -- the book by Lawrence H.
                          > Putnam and Ware Myers -- is a story of how these pioneers and master
                          > practitioners of the metrics world have come to think about and explain
                          > metrics to the rest of us.
                          >
                          > The numbers I cited came from analysis of real-world XP projects that
                          > Industrial Logic has helped coach. The analysis was conducted by
                          > Michael Mah -- who works with Mr. Putnam at QSM.
                          >
                          > The folks at QSM have taught me that good, quantitative data is possible
                          > to gather on XP/Agile projects. The secret is to stop trying to invent
                          > new metrics and work with actual metrics experts.
                          >
                          > --
                          > best regards,
                          > jk
                          >
                          > I n d u s t r i a l L o g i c , I n c .
                          > Joshua Kerievsky
                          > Founder, Extreme Programmer & Coach
                          > http://industriallogic.com
                          > 866-540-8336 (toll free)
                          > 510-540-8336 (phone)
                          > Berkeley, California
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        Your message has been successfully submitted and would be delivered to recipients shortly.