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

RE: [scrumdevelopment] Re: Disavowing the "Elaboration" Sprint

Expand Messages
  • Schiel James - SHS Malvern
    David, I ll forgive you the indulgence -- ;-) Anyway, who suggested it? I did. There s another lesson learned. I have been trying to take a light handed
    Message 1 of 30 , Dec 2, 2004
    • 0 Attachment
      David,

      I'll forgive you the indulgence -- ;-)

      Anyway, who suggested it? I did.

      There's another lesson learned.

      I have been trying to take a light handed approach to the whole thing, but
      I'm also in the role of guiding the development teams toward Scrum. I
      suppose I took the "figure-this-thing-out" role just a tad bit too far. My
      more experienced teams have been making more and more suggestions as to the
      better way to do things -- I'll be much more careful in the future to listen
      first.

      To Todd at Possibility: you're absolutely right. I wanted to add to my
      findings that my situation was not all-encompassing and that there likely
      are situations in which this kind of sprint would actually work. I neglected
      to say this before I sent it, so I appreciate you calling me on it. Good
      luck with IPSec!!

      Jim

      -----Original Message-----
      From: David A Barrett [mailto:dave.barrett@...]
      Sent: Thursday, December 02, 2004 12:35 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Disavowing the "Elaboration" Sprint

      Jim,

      Allow me to be the first to say, "Told ya so!!!" :)


      Seriously, I'm glad that you tried this and even more glad that you took
      the time to articulate why you felt it didn't work and share that with us.

      Looking at your individual points, I see some things that I find
      interesting:

      The first two points relate back to the central concept, "bring the users
      and programmers together and let them discuss how it should work" as a
      central model for agile development. Also, the Agile Manifesto that says,
      "We value working programs over detailed documentation". If we accept
      those concepts at the outset, then a lot of the "That's not how it's done
      in Scrum", makes more sense.

      The third point lines up pretty nicely with the idea that the only
      acceptable deliverable is, "a functional, potentially implementable
      feature". Clearly, documentation doesn't fit this bill.

      I'm not sure I understand the fourth point in its entirety. I will say
      that our experience is that SCRUM vastly improves the individual team
      members' sense of job satisfaction. I imagine that consigning them to a
      month of documentatin hell doesn't help much there. Another point that I
      would add on here is to ask who decided to implement the elaboration
      sprint? Was it you, or did the team decide to do that? Personally, I made
      an extreme effort to back off from the "how" aspect with my team. I help
      to organize, understand, and prioritize the work, but I really try get them
      to figure out for themselves the best way to get it done. We regularly
      have discussions about the process. Are we meeting our commitments? Are
      we creating problems for ourselves? Are we getting all the information we
      need? Are we communicating to the customers properly? Do they have any
      pet peeves? Then I try to get them to address those issues and come up
      with solutions, draw a concensus and then implement them.


      Dave Barrett,
      Lawyers' Professional Indemnity Company




      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links







      -------------------------------------------------------------------------------
      This message and any included attachments are from Siemens Medical Solutions
      USA, Inc. and are intended only for the addressee(s).
      The information contained herein may include trade secrets or privileged or
      otherwise confidential information. Unauthorized review, forwarding, printing,
      copying, distributing, or using such information is strictly prohibited and may
      be unlawful. If you received this message in error, or have reason to believe
      you are not authorized to receive it, please promptly delete this message and
      notify the sender by e-mail with a copy to Central.SecurityOffice@...

      Thank you
    • mike.dwyer1@comcast.net
      Jim: Any chance you could write up your lessons learned and ship them off to Mike Cohn as an article for the Times ? -- Mike Dwyer I Keep six faithful
      Message 2 of 30 , Dec 2, 2004
      • 0 Attachment
        Jim:
        Any chance you could write up your lessons learned and ship them off to Mike Cohn as an article for the 'Times'?
         
        --
        Mike Dwyer

        "I Keep six faithful serving-men
        Who serve me well and true:
        Their names are What and Where and When
        And How and Why and Who." - Kipling
         
        -------------- Original message --------------

        >
        >
        > David,
        >
        > I'll forgive you the indulgence -- ;-)
        >
        > Anyway, who suggested it? I did.
        >
        > There's another lesson learned.
        >
        > I have been trying to take a light handed approach to the whole thing, but
        > I'm also in the role of guiding the development teams toward Scrum. I
        > suppose I took the "figure-this-thing-out" role just a tad bit too far. My
        > more experienced teams have been making more and more suggestions as to the
        > better way to do things -- I'll be much more careful in the future to listen
        > first.
        >
        > To Todd at Possibility: you're absolutely right. I wanted to add to my
        > findings that my situation was not all-encompassing and that there likely
        > are situations in which this kind of sprint would actually work. I neglected
        > to say this before I sent it, so I appreciate you calling me on it. Good
        > luck with IPSec!!
        >
        > Jim
        >
        > -----Original Message-----
        > From: David A Barrett [mailto:dave.barrett@...]
        > Sent: Thursday, December 02, 2004 12:35 PM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] Re: Disavowing the "Elaboration" Sprint
        >
        > Jim,
        >
        > Allow me to be the first to say, "Told ya so!!!" :)
        >
        >
        > Seriously, I'm glad that you tried this and even more glad that you took
        > the time to articulate why you felt it didn't work and share that with us.
        >
        > Looking at your individual points, I see some things that I find
        > interesting:
        >
        > The first two points relate back to the central concept, "bring the users
        > and programmers together and let them discuss how it should work" as a
        > central model for agile development. Also, the Agile Manifesto that says,
        > "We value working programs over detailed documentation". If we accept
        > those concepts at the outset, then a lot of the "That's not how it's done
        > in Scrum", makes more sense.
        >
        > The third point lines up pretty nicely with the idea that the only
        > acceptable deliverable is, "a functional, potentially implementable
        > feature". Clearly, documentation doesn't fit this bill.
        >
        > I'm not sure I understand the fourth point in its entirety. I will say
        > that our experience is that SCRUM vastly improves the individual team
        > members' sense of job satisfaction. I imagine that consigning them to a
        > month of documentatin hell doesn't help much there. Another point that I
        > would add on here is to ask who decided to implement the elaboration
        > sprint? Was it you, or did the team decide to do that? Personally, I made
        > an extreme effort to back off from the "how" aspect with my team. I help
        > to organize, understand, and prioritize the work, but I really try get them
        > to figure out for themselves the best way to get it done. We regularly
        > have discussions about the process. Are we meeting our commitments? Are
        > we creating problems for ourselves? Are we getting all the information we
        > need? Are we communicating to the customers properly? Do they have any
        > pet peeves? Then I try to get them to address those issues and come up
        > with solutions, draw a concensus and then implement them.
        >
        >
        > Dave Barrett,
        > Lawyers' Professional Indemnity Company
        >
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        > -------------------------------------------------------------------------------
        > This message and any included attachments are from Siemens Medical Solutions
        > USA, Inc. and are intended only for the addressee(s).
        > The information contained herein may include trade secrets or privileged or
        > otherwise confidential information. Unauthorized review, forwarding, printing,
        > copying, distributing, or using such information is strictly prohibited and may
        > be unlawful. If you received this message in error, or have reason to believe
        > you are not authorized to receive it, please promptly delete this message and
        > notify the sender by e-mail with a copy to
        > Central.SecurityOffice@...
        >
        > Thank you
        >
        >
        > ------------------------ Yahoo! Groups Sponsor --------------------~-->
        > Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
        > Now with Pop-Up Blocker. Get it for free!
        > http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/9EfwlB/TM
        > --------------------------------------------------------------------~->
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        >
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        >
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
      • Hubert Smits
        Hi Jim, I d like to pay you a compliment for running the experiment and be willing to stand up here, and share your experiences. This is what courage (as
        Message 3 of 30 , Dec 2, 2004
        • 0 Attachment
          Hi Jim,

          I'd like to pay you a compliment for running the experiment and be
          willing to stand up here, and share your experiences. This is what
          'courage' (as defined in XP) is about, for me anyway. Thanks for
          sharing.

          --Hubert


          On Thu, 02 Dec 2004 20:48:55 +0000, mike.dwyer1@...
          <mike.dwyer1@...> wrote:
          >
          > Jim:
          > Any chance you could write up your lessons learned and ship them off to Mike
          > Cohn as an article for the 'Times'?
          >
          >
          >
          > --
          > Mike Dwyer
          >
          > "I Keep six faithful serving-men
          > Who serve me well and true:
          > Their names are What and Where and When
          > And How and Why and Who." - Kipling
          >
          > -------------- Original message --------------
          >
          > >
          > >
          > > David,
          > >
          > > I'll forgive you the indulgence -- ;-)
          > >
          > > Anyway, who suggested it? I did.
          > >
          > > There's another lesson learned.
          > >
          > > I have been trying to take a light handed approach to the whole thing, but
          > > I'm also in the role of guiding the development teams toward Scrum. I
          > > suppose I took the "figure-this-thing-out" role just a tad bit too far. My
          > > more experienced teams have been making more and more suggestions as to
          > the
          > > better way to do things -- I'll be much more careful in the future to
          > listen
          > > first.
          > >
          > > To Todd at Possibility: you're absolutely right. I wanted to add to my
          > > findings that my situation was not all-encompassing and that there likely
          > > are situations in which this kind of sprint would actually work. I
          > neglected
          > > to say this before I sent it, so I appreciate you calling me on it. Good
          > > luck with IPSec!!
          > >
          > > Jim
          > >
          > > -----Original Message-----
          > > From: David A Barrett [mailto:dave.barrett@...]
          > > Sent: Thursday, December 02, 2004 12:35 PM
          > > To: scrumdevelopment@yahoogroups.com
          > > Subject: [scrumdevelopment] Re: Disavowing the "Elaboration" Sprint
          > >
          > > Jim,
          > >
          > > Allow me to be the first to say, "Told ya so!!!" :)
          > >
          > >
          > > Seriously, I'm glad that you tried this and even more glad that you took
          > > the time to articulate why you felt it didn't work and share that with us.
          > >
          > > Looking at your individual points, I see some things that I find
          > > interesting:
          > >
          > > The first two points relate back to the central concept, "bring the users
          > > and programmers together and let them discuss how it should work" as a
          > > central model for agile development. Also, the Agile Manifesto that says,
          > > "We value working programs over detailed documentation". If we accept
          > > those concepts at the outset, then a lot of the "That's not how it's done
          > > in Scrum", makes more sense.
          > >
          > > The third point lines up pretty nicely with the idea that the only
          > > acceptable deliverable is, "a functional, potentially implementable
          > > feature". Clearly, documentation doesn't fit this bill.
          > >
          > > I'm not sure I understand the fourth point in its entirety. I will say
          > > that our experience is that SCRUM vastly improves the individual team
          > > members' sense of job satisfaction. I imagine that consigning them to a
          > > month of documentatin hell doesn't help much there. Another point that I
          > > would add on here is to ask who decided to implement the elaboration
          > > sprint? Was it you, or did the team decide to do that? Personally, I made
          > > an extreme effort to back off from the "how" aspect with my team. I help
          > > to organize, understand, and prioritize the work, but I really try get
          > them
          > > to figure out for themselves the best way to get it done. We regularly
          > > have discussions about the process. Are we meeting our commitments? Are
          > > we creating problems for ourselves? Are we getting all the information we
          > > need? Are we communicating to the customers properly? Do they have any
          > > pet peeves? Then I try to get them to address those issues and come up
          > > with solutions, draw a concensus and then implement them.
          > >
          > >
          > > Dave Barrett,
          > > Lawyers' Professional Indemnity Company
          > >
          > >
          > >
          > >
          > > To Post a message, send it to: scrumdevelopment@...
          > > To Unsubscribe, send a blank message to:
          > > scrumdevelopment-unsubscribe@...
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > -------------------------------------------------------------------------------
          > > This message and any included attachments are from Siemens Medical
          > Solutions
          > > USA, Inc. and are intended only for the addressee(s).
          > > The information contained herein may include trade secrets or privileged
          > or
          > > otherwise confidential information. Unauthorized review, forwarding,
          > printing,
          > > copying, distributing, or using such information is strictly prohibited
          > and may
          > > be unlawful. If you received this message in error, or have reason to
          > believe
          > > you are not authorized to receive it, please promptly delete this message
          > and
          > > notify the sender by e-mail with a copy to
          > > Central.SecurityOffice@...
          > >
          > > Thank you
          > >
          > >
          > >
          > > To Post a message, send it to: scrumdevelopment@...
          > > To Unsubscribe, send a blank message to:
          > > scrumdevelopment-unsubscribe@...
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          >
          >
          >
          > Yahoo! Groups Sponsor
          >
          > ADVERTISEMENT
          >
          >
          > ________________________________
          >
          >
          > Yahoo! Groups Links
          >
          > To visit your group on the web, go to:
          > http://groups.yahoo.com/group/scrumdevelopment/
          >
          > To unsubscribe from this group, send an email to:
          > scrumdevelopment-unsubscribe@yahoogroups.com
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • Stephen Haberman
          ... I agree, kudos, Jim. - Stephen
          Message 4 of 30 , Dec 2, 2004
          • 0 Attachment
            > -----Original Message-----
            > From: Hubert Smits [mailto:hubert.smits@...]
            >
            > Hi Jim,
            >
            > I'd like to pay you a compliment for running the experiment and be
            > willing to stand up here, and share your experiences. This is what
            > 'courage' (as defined in XP) is about, for me anyway. Thanks for
            > sharing.

            I agree, kudos, Jim.

            - Stephen
          • Michael Spayd
            Jim, I completely concur with Hubert s assessment about your courage . Thank you. Michael -- Michael K. Spayd COGILITY, LLC Business Mind, Social Heart
            Message 5 of 30 , Dec 2, 2004
            • 0 Attachment
              Jim, I completely concur with Hubert's assessment about your courage .
              Thank you.

              Michael


              --
              Michael K. Spayd
              COGILITY, LLC
              "Business Mind, Social Heart"
              michael.spayd@...
              720.300.5286

              On Thu, 2 Dec 2004 21:47:44 +0000, Hubert Smits <hubert.smits@...> wrote:
              > Hi Jim,
              >
              > I'd like to pay you a compliment for running the experiment and be
              > willing to stand up here, and share your experiences. This is what
              > 'courage' (as defined in XP) is about, for me anyway. Thanks for
              > sharing.
              >
              > --Hubert
              >
            • Daniel Gackle
              ... Wha? Then who does? Daniel
              Message 6 of 30 , Dec 2, 2004
              • 0 Attachment
                > Developers usually don't like unit tests either.

                Wha? Then who does?

                Daniel
              • todd
                ... I don t like flossing, yet i do. Most people don t. The vast majority of developers i have worked with don t like unit testing. I don t really like unit
                Message 7 of 30 , Dec 2, 2004
                • 0 Attachment
                  Daniel Gackle wrote:

                  > > Developers usually don't like unit tests either.
                  >
                  > Wha? Then who does?

                  I don't like flossing, yet i do. Most people don't. The vast majority
                  of developers i have worked with don't like unit testing. I don't
                  really like unit testing, but it helps prevent gingivitis, so i do it.
                • Drew Miller
                  ... I like unit testing. I like writing unit tests. I like reading unit test reports each morning. To me unit testing is a heavy blanket that keeps me warm at
                  Message 8 of 30 , Dec 3, 2004
                  • 0 Attachment
                    On Friday, December 03, 2004, at 01:03AM, todd <todd@...> wrote:

                    >I don't like flossing, yet i do. Most people don't. The vast majority
                    >of developers i have worked with don't like unit testing. I don't
                    >really like unit testing, but it helps prevent gingivitis, so i do it.

                    I like unit testing. I like writing unit tests. I like reading unit test reports each morning.

                    To me unit testing is a heavy blanket that keeps me warm at night and helps me face the next day. With it, I rarely spend half my day trying to warm up. And when I do, it is because I am actually cold. No more wind chill.

                    At first I resented having to clean this blanket every day, mend its corners, and carry it about (it is, after all, much heavier than my old, thin blanket which didn't even cover me entirely). But until I stopped resenting it, and grew to like it, I wasn't as diligent with its cleaning and mending as it needed and deserved.

                    I did grow to like it. After all, what is there to not like?

                    Regards,

                    Drew Miller
                    <drew.miller@...>
                    A code grunt who longs to be a project manager
                  • todd
                    ... I don t use a lot of blankets so that may explain it :-) Historically I have very few bugs, so it is quite a bit of work. My goal though is no bugs and
                    Message 9 of 30 , Dec 3, 2004
                    • 0 Attachment
                      Drew Miller wrote:

                      >
                      > On Friday, December 03, 2004, at 01:03AM, todd <todd@...>
                      > wrote:
                      >
                      > I did grow to like it. After all, what is there to not like? To me
                      > unit testing is a heavy blanket that keeps me warm at night and helps
                      > me face the next day. With it, I rarely spend half my day trying to
                      > warm up. And when I do, it is because I am actually cold. No more wind
                      > chill.


                      I don't use a lot of blankets so that may explain it :-) Historically I
                      have very few bugs,
                      so it is quite a bit of work. My goal though is no bugs and unit tests
                      help with that
                      goal, so i unit test. Though unit testing doesn't find integration test
                      or system
                      level test bugs, but i can find most of them. I find it interesting that
                      people hate
                      heavy process practices, but then embrace heavy coding practices. Unit
                      testing
                      is a heavy practice, but it's worth it. I have done it for my entire
                      career and i
                      evangelize like crazy. It's very rewarding when somebody gets unit testing,
                      but it's a difficult sale.
                    • Drew Miller
                      I know this thread is diverging from the list s topic, but I feel like responding anyway. Sorry. ... Next time you are looking for work send me your resume. I
                      Message 10 of 30 , Dec 3, 2004
                      • 0 Attachment
                        I know this thread is diverging from the list's topic, but I feel like responding anyway. Sorry.

                        todd wrote:

                        >Historically I have very few bugs,

                        Next time you are looking for work send me your resume. I have found few engineers who produce very few bugs. I need more.

                        That being said, I don't trust humans to execute tests. I don't really trust them to write tests either, but I haven't found an alternative yet. (Yes, I jest.)

                        >Though unit testing doesn't find integration test or system
                        >level test bugs, but i can find most of them.

                        If given the choice of automated acceptance and integration testing or unit testing, I choose the former. I hope I don't have to choose. They are, in my opinion, all important.

                        >I find it interesting that people hate
                        >heavy process practices, but then embrace heavy coding practices. Unit
                        >testing is a heavy practice, but it's worth it.

                        I hate mandated, invaluable practices of any sort. If a heavy practice is valuable (and the cost/benefit ratio is favorable) I will do it (happily). If someone was to tell me, "You must unit test all code, regardless of circumstance!," I would fight that person. Sometimes the cost/benefit ratio of unit testing isn't favorable.

                        I think there is as much danger in dismissing a practice because it is heavy as there is in adhering to a practice because it is standard or mandated.

                        >It's very rewarding when somebody gets unit testing,
                        >but it's a difficult sale.

                        I have found more often that I can sell the idea of unit testing (to a developer), but I can't get people to actually do it. Some programmers just don't care enough about their craft to spend the extra time and effort. I would tend to get rid of those people. There is nothing worse than someone who believes in something but won't act on that belief. (I have many "There is nothing worse than" sayings, which I know is somewhat contradictory.)

                        Regards,

                        Drew Miller
                        <drew.miller@...>
                        A code grunt who longs to be a project manager
                      • slightlynew
                        ... There s a good reason to hate one and embrace the other. The term heavy practice implies (to me) something that is extrinsic to the task at hand. This is
                        Message 11 of 30 , Dec 3, 2004
                        • 0 Attachment
                          > I find it interesting that people hate heavy process practices,
                          > but then embrace heavy coding practices. Unit testing is a heavy
                          > practice, but it's worth it.

                          There's a good reason to hate one and embrace the other. The
                          term "heavy practice" implies (to me) something that is extrinsic to
                          the task at hand. This is not true of unit testing at all.

                          Let's remember the context in which this came up. An argument was
                          made that writing detailed requirements documents is analogous to
                          writing unit tests. Developers don't like to do either, but they
                          should be made to do them (at least "when necessary").

                          Well, I disagree. Detailed requirements documents get in the way of
                          productive software development, while unit testing (TDD) improves
                          and enriches it.

                          None of the developers I admire likes writing detailed requirements
                          documents. Why? Because it isn't possible to get them right. The
                          feedback provided by implementation is necessary to learn what the
                          detailed requirements really are. Detailed requirements documents
                          are sterile.

                          But all of the developers I admire like writing unit tests. Why?
                          Because it is their way of specifying and clarifying what the
                          software needs to do. Unit testing is a feedback loop that a deep
                          and intrinsic part of their work.

                          In fact, well-written automated tests /are/ detailed requirements
                          documents. That's part of why the rediscovery of automated testing
                          in agile is so important. It's a discovery about the nature of
                          software development, namely that the dialectic between production
                          code and test code is the /effective/ way to move between
                          specification and implementation, in contrast to the ineffective way
                          represented by detailed requirements documents.

                          The trouble with the above argument is that it acts as if iterative
                          and agile development don't exist.

                          Daniel
                        • todd
                          ... Coding does not require unit testing. Most of the working code in the world does not have unit tests. Thus unit tests are extrinsic. I have drunk the unit
                          Message 12 of 30 , Dec 4, 2004
                          • 0 Attachment
                            slightlynew wrote:

                            >
                            > > I find it interesting that people hate heavy process practices,
                            > > but then embrace heavy coding practices. Unit testing is a heavy
                            > > practice, but it's worth it.
                            >
                            > There's a good reason to hate one and embrace the other. The
                            > term "heavy practice" implies (to me) something that is extrinsic to
                            > the task at hand. This is not true of unit testing at all.

                            Coding does not require unit testing. Most of the working code in the world
                            does not have unit tests. Thus unit tests are extrinsic.

                            I have drunk the unit testing cool aide, but if you bypass the cost of
                            something
                            you lose credibility with those you are talking with. I have learned
                            this through
                            many many conversations with developers who consider unit testing a lot
                            of extra work up front and a lot of extra maintenance work. Saying it's not
                            a lot of work doesn't give you much street cred. You and I may think we
                            have excellent reasons for doing the work, but it is still a lot of work.

                            > Well, I disagree. Detailed requirements documents get in the way of
                            > productive software development, while unit testing (TDD) improves
                            > and enriches it.

                            What is a detailed requirement? The requirements for producing an
                            acceptance testable
                            credit card purchasing module seem extremely detailed to me. If by
                            detailed you mean
                            an exact class diagram then I agree. Even to create a product backlog
                            you have to
                            go into a great deal of detail.

                            > In fact, well-written automated tests /are/ detailed requirements
                            > documents.

                            It depends on your audience. To my customer the requirement is implement
                            ipsec.
                            This will expand out to 1000s of detailed tests. That doesn't help them
                            much.
                            It doesn't help me as a developer much either. I need a step-wise breakdown
                            of functionality so i can iteratively build up my mental models. Being
                            presented
                            with a very fine level of detail when i am not ready just confuses me.

                            > That's part of why the rediscovery of automated testing
                            > in agile is so important.

                            Um, no rediscovery at all. Many of us have been doing automated testing at
                            every level for a very long time.

                            > It's a discovery about the nature of
                            > software development, namely that the dialectic between production
                            > code and test code is the /effective/ way to move between
                            > specification and implementation, in contrast to the ineffective way
                            > represented by detailed requirements documents.

                            A dialectical process that must be constrained to stay within your ideal
                            system isn't
                            all that useful.
                          • Todd Hartle
                            ... So if this is the case (which I believe it is) then a) Why is all that code working at all?; and b) Why have so many drunk the cool aide? The issue I come
                            Message 13 of 30 , Dec 8, 2004
                            • 0 Attachment
                              > Coding does not require unit testing. Most of the working code in the world
                              > does not have unit tests. Thus unit tests are extrinsic.
                              >

                              So if this is the case (which I believe it is) then a) Why is all that
                              code working at all?; and b) Why have so many drunk the cool aide?

                              The issue I come up against more often than not is not unit testing
                              per se but the *definition* of unit testing. Most of my colleague who
                              thrive on OOP seem to forget that unit testing did exist before OOP
                              become popular. Thoughts?


                              On Sat, 04 Dec 2004 10:57:48 -0800, todd <todd@...> wrote:
                              >
                              > slightlynew wrote:
                              >
                              > >
                              > > > I find it interesting that people hate heavy process practices,
                              > > > but then embrace heavy coding practices. Unit testing is a heavy
                              > > > practice, but it's worth it.
                              > >
                              > > There's a good reason to hate one and embrace the other. The
                              > > term "heavy practice" implies (to me) something that is extrinsic to
                              > > the task at hand. This is not true of unit testing at all.
                              >
                              > Coding does not require unit testing. Most of the working code in the world
                              > does not have unit tests. Thus unit tests are extrinsic.
                              >
                              > I have drunk the unit testing cool aide, but if you bypass the cost of
                              > something
                              > you lose credibility with those you are talking with. I have learned
                              > this through
                              > many many conversations with developers who consider unit testing a lot
                              > of extra work up front and a lot of extra maintenance work. Saying it's not
                              > a lot of work doesn't give you much street cred. You and I may think we
                              > have excellent reasons for doing the work, but it is still a lot of work.
                              >
                              > > Well, I disagree. Detailed requirements documents get in the way of
                              > > productive software development, while unit testing (TDD) improves
                              > > and enriches it.
                              >
                              > What is a detailed requirement? The requirements for producing an
                              > acceptance testable
                              > credit card purchasing module seem extremely detailed to me. If by
                              > detailed you mean
                              > an exact class diagram then I agree. Even to create a product backlog
                              > you have to
                              > go into a great deal of detail.
                              >
                              > > In fact, well-written automated tests /are/ detailed requirements
                              > > documents.
                              >
                              > It depends on your audience. To my customer the requirement is implement
                              > ipsec.
                              > This will expand out to 1000s of detailed tests. That doesn't help them
                              > much.
                              > It doesn't help me as a developer much either. I need a step-wise breakdown
                              > of functionality so i can iteratively build up my mental models. Being
                              > presented
                              > with a very fine level of detail when i am not ready just confuses me.
                              >
                              > > That's part of why the rediscovery of automated testing
                              > > in agile is so important.
                              >
                              > Um, no rediscovery at all. Many of us have been doing automated testing at
                              > every level for a very long time.
                              >
                              > > It's a discovery about the nature of
                              > > software development, namely that the dialectic between production
                              > > code and test code is the /effective/ way to move between
                              > > specification and implementation, in contrast to the ineffective way
                              > > represented by detailed requirements documents.
                              >
                              > A dialectical process that must be constrained to stay within your ideal
                              > system isn't
                              > all that useful.
                              >
                              >
                              > To Post a message, send it to: scrumdevelopment@...
                              > To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@...
                              >
                              >
                              >
                              > Yahoo! Groups Sponsor
                              >
                              > ADVERTISEMENT
                              >
                              >
                              > ________________________________
                              > Yahoo! Groups Links
                              >
                              > To visit your group on the web, go to:
                              > http://groups.yahoo.com/group/scrumdevelopment/
                              >
                              > To unsubscribe from this group, send an email to:
                              > scrumdevelopment-unsubscribe@yahoogroups.com
                              >
                              > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                            • Ron Jeffries
                              ... Yes. However, debugging and fixing also costs a lot. So if you want to have software at a reasonably low level of defects, it just might be that unit
                              Message 14 of 30 , Dec 8, 2004
                              • 0 Attachment
                                On Saturday, December 4, 2004, at 1:57:48 PM, todd wrote:

                                > Coding does not require unit testing. Most of the working code in the world
                                > does not have unit tests. Thus unit tests are extrinsic.

                                > I have drunk the unit testing cool aide, but if you bypass the
                                > cost of something you lose credibility with those you are talking
                                > with. I have learned this through many many conversations with
                                > developers who consider unit testing a lot of extra work up front
                                > and a lot of extra maintenance work. Saying it's not a lot of work
                                > doesn't give you much street cred. You and I may think we have
                                > excellent reasons for doing the work, but it is still a lot of
                                > work.

                                Yes. However, debugging and fixing also costs a lot. So if you want
                                to have software at a reasonably low level of defects, it just might
                                be that unit testing costs less than (not unit testing plus
                                debugging plus fixing).

                                Ron Jeffries
                                www.XProgramming.com
                                Comments lie. Code doesn't.
                              • todd
                                ... I am positive you don t need unit tests to write good code. But it helps. How many bugs do you normally write? How many of those will be caught by system
                                Message 15 of 30 , Dec 8, 2004
                                • 0 Attachment
                                  Todd Hartle wrote:

                                  > So if this is the case (which I believe it is) then a) Why is all that
                                  > code working at all?;

                                  I am positive you don't need unit tests to write good code. But it helps.
                                  How many bugs do you normally write? How many of those will be
                                  caught by system tests and acceptance tests? How many of those will
                                  actually make a difference? If they made a difference how is it your
                                  acceptance tests didn't find them?

                                  > b) Why have so many drunk the cool aide?

                                  It's an idea with attractive benefits and real costs. People make
                                  their decision based on their own ROI calculation. Nothing
                                  deep, but it's clear people can rationally determine that the costs
                                  aren't worth the benefits.

                                  And i don't really think that many have drunk the cool aid.
                                  Out of total lines programmed i bet it's not much of a dent.

                                  >
                                  > The issue I come up against more often than not is not unit testing
                                  > per se but the *definition* of unit testing.

                                  Definitions with software folk always seem to be good fuel for the flame
                                  war :-)
                                  I am sure my definition probably doesn't agree with yours or most of the
                                  other people on the list.

                                  > Most of my colleague who
                                  > thrive on OOP seem to forget that unit testing did exist before OOP
                                  > become popular. Thoughts?

                                  But does that stop them from unit testing?
                                • Todd Hartle
                                  However, not unit testing does not imply not testing all. And it also seems that unit testing can still exist even though the tests do not live in the code. On
                                  Message 16 of 30 , Dec 9, 2004
                                  • 0 Attachment
                                    However, not unit testing does not imply not testing all. And it also
                                    seems that unit testing can still exist even though the tests do not
                                    live in the code.


                                    On Wed, 8 Dec 2004 23:29:35 -0500, Ron Jeffries
                                    <ronjeffries@...> wrote:
                                    > On Saturday, December 4, 2004, at 1:57:48 PM, todd wrote:
                                    >
                                    >
                                    >
                                    > > Coding does not require unit testing. Most of the working code in the
                                    > world
                                    > > does not have unit tests. Thus unit tests are extrinsic.
                                    >
                                    > > I have drunk the unit testing cool aide, but if you bypass the
                                    > > cost of something you lose credibility with those you are talking
                                    > > with. I have learned this through many many conversations with
                                    > > developers who consider unit testing a lot of extra work up front
                                    > > and a lot of extra maintenance work. Saying it's not a lot of work
                                    > > doesn't give you much street cred. You and I may think we have
                                    > > excellent reasons for doing the work, but it is still a lot of
                                    > > work.
                                    >
                                    > Yes. However, debugging and fixing also costs a lot. So if you want
                                    > to have software at a reasonably low level of defects, it just might
                                    > be that unit testing costs less than (not unit testing plus
                                    > debugging plus fixing).
                                    >
                                    > Ron Jeffries
                                    > www.XProgramming.com
                                    > Comments lie. Code doesn't.
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > To Post a message, send it to: scrumdevelopment@...
                                    > To Unsubscribe, send a blank message to:
                                    > scrumdevelopment-unsubscribe@...
                                    >
                                    >
                                    >
                                    > Yahoo! Groups Sponsor
                                    >
                                    > ADVERTISEMENT
                                    >
                                    >
                                    > ________________________________
                                    > Yahoo! Groups Links
                                    >
                                    > To visit your group on the web, go to:
                                    > http://groups.yahoo.com/group/scrumdevelopment/
                                    >
                                    > To unsubscribe from this group, send an email to:
                                    > scrumdevelopment-unsubscribe@yahoogroups.com
                                    >
                                    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                    >
                                    >
                                  • Mike Dwyer
                                    The real electric Cool Aid Test lives in the dark side of software - maintenance and problem resolution. Since it is here that you can see the hubris of those
                                    Message 17 of 30 , Dec 10, 2004
                                    • 0 Attachment
                                      The real electric Cool Aid Test lives in the dark side of software -
                                      maintenance and problem resolution. Since it is here that you can see the
                                      hubris of those who felt their code was too smooth, too simple, or too cool
                                      to need a unit test. Is there a lot of energy in that statement? Yup. So
                                      perhaps I should rephrase.

                                      It is rare to see code come into the shop that had well designed unit tests.
                                      That is to say tests that

                                      Defined the input, tested all combinations of input, tested to make sure
                                      they could tell good input from bad.

                                      Insured that all logic flows had errors trapped - with some meaningful
                                      documented schema to tell where the error came from.

                                      Validated that all the output meant the interface requirements that the
                                      users of the software had stated they needed.

                                      Documented all of the conditions that could occur that were not covered by
                                      the interface specification

                                      Now the really GOOD engineers had a parm you could pass that would open up
                                      the dbug logic in the software so that we grunts on the dark side had some
                                      idea what was going on.

                                      Finally, speaking from my tenure as chief testing troll, the REALLY GOOD AND
                                      SMART Engineers enlisted a testing troll in testing the tests.

                                      Michael F. Dwyer

                                      Mike.Dwyer1@...



                                      -----Original Message-----
                                      From: Ron Jeffries [mailto:ronjeffries@...]
                                      Sent: Wednesday, December 08, 2004 11:30 PM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] Re: UnitTesting


                                      On Saturday, December 4, 2004, at 1:57:48 PM, todd wrote:

                                      > Coding does not require unit testing. Most of the working code in the
                                      world
                                      > does not have unit tests. Thus unit tests are extrinsic.

                                      > I have drunk the unit testing cool aide, but if you bypass the
                                      > cost of something you lose credibility with those you are talking
                                      > with. I have learned this through many many conversations with
                                      > developers who consider unit testing a lot of extra work up front
                                      > and a lot of extra maintenance work. Saying it's not a lot of work
                                      > doesn't give you much street cred. You and I may think we have
                                      > excellent reasons for doing the work, but it is still a lot of
                                      > work.

                                      Yes. However, debugging and fixing also costs a lot. So if you want
                                      to have software at a reasonably low level of defects, it just might
                                      be that unit testing costs less than (not unit testing plus
                                      debugging plus fixing).

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Comments lie. Code doesn't.





                                      To Post a message, send it to: scrumdevelopment@...
                                      To Unsubscribe, send a blank message to:
                                      scrumdevelopment-unsubscribe@...
                                      Yahoo! Groups Links
                                    • Phlip
                                      ... If you don t write unit tests before writing code, your tests won t easily cover everything, and you will spend more time debugging. Folks who use TDD very
                                      Message 18 of 30 , Dec 10, 2004
                                      • 0 Attachment
                                        Todd Hartle wrote:
                                        >
                                        > However, not unit testing does not imply not testing all. And it also
                                        > seems that unit testing can still exist even though the tests do not
                                        > live in the code.

                                        If you don't write unit tests before writing code, your tests won't
                                        easily cover everything, and you will spend more time debugging.

                                        Folks who use TDD very frequently report _zero_ debugger usage.

                                        Think of it like this: Each time you debug, you set a breakpoint, you
                                        run the program and load sample data, you hit the breakpoint, and you
                                        inspect the local values to see if they are correct with respect to
                                        the sample data.

                                        TDD converts debugging into a system that records an endless trail of
                                        each of these experiments. Going forward into maintenance, for each
                                        change you make, you get an invisible programmer debugging your code,
                                        over thousands of scenarios, in a second.

                                        --
                                        Phlip
                                      • Angelo Schneider
                                        Hi, unit testing as it is emphasized today in TDD and XP has mainly two backgrounds: a) in XP you do not very detailed requirements analysis, but story boards
                                        Message 19 of 30 , Dec 10, 2004
                                        • 0 Attachment
                                          Hi,

                                          unit testing as it is emphasized today in TDD and XP has mainly two
                                          backgrounds:

                                          a) in XP you do not very detailed requirements analysis, but story
                                          boards and planning games, like CRC card sessions.

                                          So, writing unit tests first helps the programmer to understand the
                                          requirements. With "the customer in house" you can use (and must use)
                                          the tests to validate wether your requirements are right. Further:
                                          writing a lot of unit tests comes from the Smalltak development
                                          fraction where your unit tests partly replace the compiler type
                                          checking and also lint.

                                          b) Your main goal in having unit tests is to have a "regression test
                                          suit" in case you do refactorings, bug fixes or you simply continue in
                                          your next development goal.

                                          Finally: no, most software development shops have no clue how to value
                                          wether they "need" unit tests or not. If you ask one who does not do
                                          unit tests he will ALWAYS claim he either does not need so or they
                                          don't bring him any value (ROI). Likewise everybody doing them knows
                                          that they bring him ROI, like I pointed out in b) As long as one never
                                          doing unit tests ever does one, he has no numbers from which he could
                                          judge. Most of the time people not having unit tests have no decent
                                          issue tracking/bug fixing/project tracking either. So how should they
                                          know how much it costs them NOT TO DO TDD?

                                          I disagree that detailed requirement analysis does not work, and also I
                                          disagree that the tests are needed to get the requirements fixed. Often
                                          this may be the case but as a general rule its far to strong.

                                          Suppose you don't do a use case and a few scenarios, but write the test
                                          and the code which passes that test. And now? Now you check wether the
                                          code/test is right. Thats expensive, especially if the code and test is
                                          wrong!

                                          Before you code, regardless wether with TDD or not, you should do
                                          planning games with paper sheets where you have a paper form holding
                                          data and objects and you pass them around between requirements analysts
                                          like in CRC or XP planning games.

                                          If you start directly with TDD you are not "coding" but "prototyping"
                                          ... a completely different approach with different goals (throw away
                                          e.g.).

                                          Regarding OOP reinvented unit tests ... no they did not. In OOP unit
                                          tests are far more complicated than in C/pascal like languages because
                                          its harder to write stubs.

                                          Instead of writing unit tests, I always start with writing tests based
                                          on a scenario. That does give me an integration test over a small
                                          subsystem. All scenarios should cover all the code written for a full
                                          use case. A coverage tool helps. When the software evolves and
                                          "libraries" for it get crafted and refactoring gets more and more we
                                          start writing unit tests. In general we have far more "scenario" tests
                                          than unit tests. As some posters here where right: that bad code we
                                          don't write. So if our scenario tests have a full coverage we hope they
                                          hold. We don't make avionic systems here :D But well, that risk we
                                          judge depending on likelihood and cost of failure.

                                          Regards,
                                          Angelo

                                          --------------------------- www.oomentor.de --------------------------
                                          Angelo Schneider OOAD/UML Angelo.Schneider@...
                                          Putlitzstr. 24 Patterns/FrameWorks Fon: +49 721 9812465
                                          76137 Karlsruhe C++/JAVA Fax: +49 721 9812467
                                        • Ron Jeffries
                                          Angelo, I have some comments below addressing what seem to be misunderstandings about XP and TDD, and some questions. Thanks, ... Actually, with the customer
                                          Message 20 of 30 , Dec 11, 2004
                                          • 0 Attachment
                                            Angelo,

                                            I have some comments below addressing what seem to be
                                            misunderstandings about XP and TDD, and some questions.

                                            Thanks,

                                            On Friday, December 10, 2004, at 11:25:43 PM, Angelo Schneider wrote:

                                            > unit testing as it is emphasized today in TDD and XP has mainly two
                                            > backgrounds:

                                            > a) in XP you do not very detailed requirements analysis, but story
                                            > boards and planning games, like CRC card sessions.

                                            Actually, with the customer present in the room for extensive
                                            conversation, and with the requirement being that the /customer/
                                            defines extensive Customer Acceptance Tests, XP's requirements
                                            analysis is in fact very detailed. It just isn't done in the form,
                                            or at the time, that it might be in another method.

                                            For a bit more on that, see
                                            http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm .

                                            > So, writing unit tests first helps the programmer to understand the
                                            > requirements. With "the customer in house" you can use (and must use)
                                            > the tests to validate wether your requirements are right.

                                            The tests that verify requirements are the Customer Acceptance
                                            Tests. The unit tests help understand the design, more so than the
                                            requirements.

                                            > Further:
                                            > writing a lot of unit tests comes from the Smalltak development
                                            > fraction where your unit tests partly replace the compiler type
                                            > checking and also lint.

                                            Actually Smalltalk has lint. And unit tests cover matters that
                                            compiler type checking and lint do not: they test whether the
                                            answers are correct, not just of the correct type.

                                            > b) Your main goal in having unit tests is to have a "regression test
                                            > suit" in case you do refactorings, bug fixes or you simply continue in
                                            > your next development goal.

                                            Yes, the tests do also support refactoring. I'm not sure whether
                                            that is the main goal, but it is an important goal.

                                            > Finally: no, most software development shops have no clue how to value
                                            > wether they "need" unit tests or not. If you ask one who does not do
                                            > unit tests he will ALWAYS claim he either does not need so or they
                                            > don't bring him any value (ROI). Likewise everybody doing them knows
                                            > that they bring him ROI, like I pointed out in b) As long as one never
                                            > doing unit tests ever does one, he has no numbers from which he could
                                            > judge. Most of the time people not having unit tests have no decent
                                            > issue tracking/bug fixing/project tracking either. So how should they
                                            > know how much it costs them NOT TO DO TDD?

                                            OK ...

                                            > I disagree that detailed requirement analysis does not work, and also I
                                            > disagree that the tests are needed to get the requirements fixed. Often
                                            > this may be the case but as a general rule its far to strong.

                                            I'm not sure whether anyone has come out against requirements
                                            analysis. I prefer that requirements be expressed in unambiguous
                                            tests rather than ambiguous human language which can be written
                                            incorrectly without getting compiler errors, and misunderstood by
                                            the reader without throwing exceptions.

                                            I would argue that /Customer Acceptance Tests/ do in fact fix the
                                            requirements more precisely than most, if not all, other forms of
                                            requirements documentation.

                                            > Suppose you don't do a use case and a few scenarios, but write the test
                                            > and the code which passes that test. And now? Now you check wether the
                                            > code/test is right. Thats expensive, especially if the code and test is
                                            > wrong!

                                            I don't understand this statement.

                                            > Before you code, regardless wether with TDD or not, you should do
                                            > planning games with paper sheets where you have a paper form holding
                                            > data and objects and you pass them around between requirements analysts
                                            > like in CRC or XP planning games.

                                            This "should" statement seems to me to be unsupported by the
                                            preceding argument. I'm not sure what practices you are
                                            distinguishing this one from, and I'd like to hear why it's so
                                            desirable in your opinion.

                                            > If you start directly with TDD you are not "coding" but "prototyping"
                                            > ... a completely different approach with different goals (throw away
                                            > e.g.).

                                            If that were true, then we'd be throwing away the code we build with
                                            TDD. But we do not throw it away. Therefore TDD is not prototyping
                                            at all.

                                            > Regarding OOP reinvented unit tests ... no they did not. In OOP unit
                                            > tests are far more complicated than in C/pascal like languages because
                                            > its harder to write stubs.

                                            I do not understand this.

                                            > Instead of writing unit tests, I always start with writing tests based
                                            > on a scenario. That does give me an integration test over a small
                                            > subsystem. All scenarios should cover all the code written for a full
                                            > use case.

                                            This sounds to me to be exactly like XP's required Customer
                                            Acceptance Tests, except that the customer writes them, which
                                            reduces the possibility that the programmers have misunderstood
                                            the requirements. In your description above, you express concern
                                            that with TDD the program might not match the requirement. In XP
                                            this concern is addressed by the independent source of the customer
                                            tests. How is that same concern addressed in what you are describing
                                            here?

                                            > A coverage tool helps. When the software evolves and
                                            > "libraries" for it get crafted and refactoring gets more and more we
                                            > start writing unit tests. In general we have far more "scenario" tests
                                            > than unit tests. As some posters here where right: that bad code we
                                            > don't write. So if our scenario tests have a full coverage we hope they
                                            > hold. We don't make avionic systems here :D But well, that risk we
                                            > judge depending on likelihood and cost of failure.

                                            How's your bug list in the shipped code? If it's very low, then what
                                            you're doing is probably working just fine. That makes it another
                                            good way to work. It would be difficult to compare both ways based
                                            on two different teams' experience. They would probably each have to
                                            try a different approach to see what happened.

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Replacing an on-site customer with some use cases is about as effective
                                            as replacing a hug from your Mom with a friendly note.
                                          • Angelo Schneider
                                            ... Thanx :D You are welcome! ... Customer Acceptance Tests, I called scenario tests below. Your term however is more appropriated. Sorry, I think in
                                            Message 21 of 30 , Dec 11, 2004
                                            • 0 Attachment
                                              Am 11.12.2004 um 10:11 schrieb Ron Jeffries:

                                              >
                                              > Angelo,
                                              >
                                              > I have some comments below addressing what seem to be
                                              > misunderstandings about XP and TDD, and some questions.
                                              >
                                              Thanx :D You are welcome!

                                              > Thanks,
                                              >
                                              > On Friday, December 10, 2004, at 11:25:43 PM, Angelo Schneider wrote:
                                              >
                                              >> unit testing as it is emphasized today in TDD and XP has mainly two
                                              >> backgrounds:
                                              >
                                              >> a) in XP you do not very detailed requirements analysis, but story
                                              >> boards and planning games, like CRC card sessions.
                                              >
                                              > Actually, with the customer present in the room for extensive
                                              > conversation, and with the requirement being that the /customer/
                                              > defines extensive Customer Acceptance Tests, XP's requirements

                                              Customer Acceptance Tests, I called "scenario tests" below. Your term
                                              however is more appropriated. Sorry, I "think in german" often when I
                                              write something.

                                              > analysis is in fact very detailed. It just isn't done in the form,
                                              > or at the time, that it might be in another method.
                                              >
                                              > For a bit more on that, see
                                              > http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm .
                                              >
                                              >> So, writing unit tests first helps the programmer to understand the
                                              >> requirements. With "the customer in house" you can use (and must use)
                                              >> the tests to validate wether your requirements are right.
                                              >
                                              > The tests that verify requirements are the Customer Acceptance
                                              > Tests. The unit tests help understand the design, more so than the
                                              > requirements.
                                              >
                                              >> Further:
                                              >> writing a lot of unit tests comes from the Smalltak development
                                              >> fraction where your unit tests partly replace the compiler type
                                              >> checking and also lint.
                                              >
                                              > Actually Smalltalk has lint. And unit tests cover matters that
                                              > compiler type checking and lint do not: they test whether the
                                              > answers are correct, not just of the correct type.

                                              Of course! But my point was (my whole awnser here mixed several answers
                                              to several posts together) that TDD has several different approaches
                                              and as that different points of view.

                                              XP comes IMHO from the Smalltalk niece. There are classes of errors
                                              which are easyly found by a compiler, but are only found by unit tests
                                              if you use languages like python/smalltalk/php etc.
                                              While people where talking in this thread about cost and benefit of TDD
                                              I liked to point out that Costs for a big suit of unit tests might be
                                              high in Java (and ROI low) while they are essential in Smalltalk/Python
                                              etc. (and ROI high).

                                              >
                                              >> b) Your main goal in having unit tests is to have a "regression test
                                              >> suit" in case you do refactorings, bug fixes or you simply continue in
                                              >> your next development goal.
                                              >
                                              > Yes, the tests do also support refactoring. I'm not sure whether
                                              > that is the main goal, but it is an important goal.

                                              Probably I exagerated, this is th goal I sell. Surprisingly often
                                              people don't want refactoring. So I try to sell unit tests (user
                                              acceptance tests) first. After 3 or 4 iterations we need refactorings
                                              and they fear the system might break and I say: no we have the tests.

                                              >
                                              >> Finally: no, most software development shops have no clue how to value
                                              >> wether they "need" unit tests or not. If you ask one who does not do
                                              >> unit tests he will ALWAYS claim he either does not need so or they
                                              >> don't bring him any value (ROI). Likewise everybody doing them knows
                                              >> that they bring him ROI, like I pointed out in b) As long as one never
                                              >> doing unit tests ever does one, he has no numbers from which he could
                                              >> judge. Most of the time people not having unit tests have no decent
                                              >> issue tracking/bug fixing/project tracking either. So how should they
                                              >> know how much it costs them NOT TO DO TDD?
                                              >
                                              > OK ...
                                              >
                                              >> I disagree that detailed requirement analysis does not work, and also
                                              >> I
                                              >> disagree that the tests are needed to get the requirements fixed.
                                              >> Often
                                              >> this may be the case but as a general rule its far to strong.
                                              >
                                              > I'm not sure whether anyone has come out against requirements
                                              > analysis. I prefer that requirements be expressed in unambiguous
                                              > tests rather than ambiguous human language which can be written

                                              If you an not write an "use acceptance test" for a certain requirement,
                                              that requirement is likely not ready to be implemented.
                                              As I pointed out below, there are differencs if you consciously decide
                                              to make a prototype.

                                              > incorrectly without getting compiler errors, and misunderstood by
                                              > the reader without throwing exceptions.
                                              >
                                              > I would argue that /Customer Acceptance Tests/ do in fact fix the
                                              > requirements more precisely than most, if not all, other forms of
                                              > requirements documentation.

                                              Yes, but people where talkin about UNIT TESTS. So probably while I
                                              mixed up "scenario tests" with "user acceptance tests" they mixed up
                                              "unit test" with "user acceptance test" :D

                                              >
                                              >> Suppose you don't do a use case and a few scenarios, but write the
                                              >> test
                                              >> and the code which passes that test. And now? Now you check wether the
                                              >> code/test is right. Thats expensive, especially if the code and test
                                              >> is
                                              >> wrong!
                                              >
                                              > I don't understand this statement.

                                              Erm, well. I ment thist: suppose you dont do tests at all. Then you
                                              only code. You produce code and defects. We know the later you find a
                                              defect the more it costs (bottom line) to fix. So a defect found after
                                              product realease, but introduced in "requirements analysis" is the most
                                              expensive (basically you shipped the wrong feature and the whole code
                                              around the wrong feature is obsolete). A defect introduced in "writing
                                              the test" and "writing the first code for that test" but introduced in
                                              RA is still more expensive than a defect found in a planning game or
                                              review based on that RA. So: my conclusion is, if your "goal" is clear
                                              enough that you do not need a prototype, don't write a prototype but
                                              write the code you plan to deliver.

                                              For that I propose a clear use case and some scenarios (and validate
                                              those in a planning game) so that you can write "user acceptance tests"
                                              and not only simple unit tests.

                                              >
                                              >> Before you code, regardless wether with TDD or not, you should do
                                              >> planning games with paper sheets where you have a paper form holding
                                              >> data and objects and you pass them around between requirements
                                              >> analysts
                                              >> like in CRC or XP planning games.
                                              >
                                              > This "should" statement seems to me to be unsupported by the
                                              > preceding argument. I'm not sure what practices you are
                                              > distinguishing this one from, and I'd like to hear why it's so
                                              > desirable in your opinion.

                                              As I tried to explain above: make the time gap between possible
                                              introduction of a defect/misconception and discovery of it (if it
                                              manifests in code its late, to late) as short as possible.

                                              >> If you start directly with TDD you are not "coding" but "prototyping"
                                              >> ... a completely different approach with different goals (throw away
                                              >> e.g.).
                                              >
                                              > If that were true, then we'd be throwing away the code we build with
                                              > TDD. But we do not throw it away. Therefore TDD is not prototyping
                                              > at all.

                                              Some of the mails before just indicated that. They indicated that its
                                              more important to write a test than to understand what the final code
                                              should do. So if your test was wrong, your code was as well and you had
                                              to throw it away.

                                              Sorry, I answered to 4 or 5 posts in one, so I might had made a
                                              confusing long mail :D

                                              >
                                              >> Regarding OOP reinvented unit tests ... no they did not. In OOP unit
                                              >> tests are far more complicated than in C/pascal like languages because
                                              >> its harder to write stubs.
                                              >
                                              > I do not understand this.

                                              Again an answer to one of the other mails :-/ Seems I really shoot
                                              myself into the foot.
                                              One guy claimed in a side note that OOP enthusiasts think they had
                                              invented TDD ... and said, that test driven development or unit tests
                                              are old. And he was right (in respect that good testing practice IS
                                              old). However, with Smalltalk (dynamic typed) and XP and JUnit etc. TDD
                                              suddenly became "en vouge".

                                              I just liked to point out that unit tests are more complicated in OOP
                                              than in C/Pascal ... because of virtual methods and more work in
                                              stubbing.

                                              >
                                              >> Instead of writing unit tests, I always start with writing tests based
                                              >> on a scenario. That does give me an integration test over a small
                                              >> subsystem. All scenarios should cover all the code written for a full
                                              >> use case.
                                              >
                                              > This sounds to me to be exactly like XP's required Customer
                                              > Acceptance Tests, except that the customer writes them, which
                                              > reduces the possibility that the programmers have misunderstood
                                              > the requirements. In your description above, you express concern
                                              > that with TDD the program might not match the requirement. In XP
                                              > this concern is addressed by the independent source of the customer
                                              > tests. How is that same concern addressed in what you are describing
                                              > here?

                                              You are right ... and what you say is what I wanted to say. My concern
                                              was the terms "unit test" and "user acceptance test", the later I
                                              called "scenario test".

                                              The main discussion was about TDD and unit tests. And for me TDD !=
                                              "unit tests"!!! TDD == "user acceptance tests"!!!!

                                              Basically :D to make my long post short and my even longer answer even
                                              shorter: Unit tests are important to get a test suit to guarantee solid
                                              code during refactorings, they ensure quality and ~~verify~~
                                              correctness (is the code fine?). User Acceptance tests ensure you write
                                              the code the customer wants. Do I write the "right product"? They
                                              ~~validate~~ that I do what I'm payed for.

                                              Writing a test first helps in both cases, but I find the later more
                                              important to start with and the former more important to catch up with
                                              during late iterations.

                                              >
                                              >> A coverage tool helps. When the software evolves and
                                              >> "libraries" for it get crafted and refactoring gets more and more we
                                              >> start writing unit tests. In general we have far more "scenario" tests
                                              >> than unit tests. As some posters here where right: that bad code we
                                              >> don't write. So if our scenario tests have a full coverage we hope
                                              >> they
                                              >> hold. We don't make avionic systems here :D But well, that risk we
                                              >> judge depending on likelihood and cost of failure.
                                              >
                                              > How's your bug list in the shipped code? If it's very low, then what
                                              > you're doing is probably working just fine. That makes it another

                                              *I* never had a bug in a shipped code.

                                              My last project where *I* was "leading architect" but unfortunately not
                                              heard in "process" had about 10 bugs and about 25 wrong stated
                                              requirements (and so they implemented wrong) and we had (nearly) no
                                              automated UAT because the customer never made them clear enough.

                                              > good way to work. It would be difficult to compare both ways based
                                              > on two different teams' experience. They would probably each have to
                                              > try a different approach to see what happened.

                                              Oh, did not want to propose a different way. I liked to point out that
                                              TDD not necessarily means "unit tests" but far more important (IMHO)
                                              means "user acceptance tests".

                                              My thesis, if you want to call it like that, is: automated UAT should
                                              give you 100% code coverage. But again, don't get me wrong, thats not
                                              enough for high critical systems!!! There you need definitely also
                                              "unit tests". Because you want a statement about the quality of every
                                              single "piece" of code.

                                              >
                                              > Ron Jeffries
                                              > www.XProgramming.com
                                              > Replacing an on-site customer with some use cases is about as effective
                                              > as replacing a hug from your Mom with a friendly note.
                                              >

                                              --------------------------- www.oomentor.de --------------------------
                                              Angelo Schneider OOAD/UML Angelo.Schneider@...
                                              Putlitzstr. 24 Patterns/FrameWorks Fon: +49 721 9812465
                                              76137 Karlsruhe C++/JAVA Fax: +49 721 9812467
                                            • Gary F
                                              ... Other types of testing don t have the same benefit with regard to debugging that unit tests have. They certainly have other types of value, but unit tests
                                              Message 22 of 30 , Dec 12, 2004
                                              • 0 Attachment
                                                --- Todd Hartle <thartle@...> wrote:

                                                >
                                                > However, not unit testing does not imply not testing all. And it also
                                                > seems that unit testing can still exist even though the tests do not
                                                > live in the code.

                                                Other types of testing don't have the same benefit with regard to debugging that unit tests have.
                                                They certainly have other types of value, but unit tests provide a tremendous tool for isolating
                                                bugs.

                                                I'm not sure what you mean by "tests do not live in the code." Could you rephrase that, please?

                                                Gary


                                                __________________________________________________
                                                Do You Yahoo!?
                                                Tired of spam? Yahoo! Mail has the best spam protection around
                                                http://mail.yahoo.com
                                              • Phlip
                                                ... TDD often goes a little farther, into preventing bugs. When you write a failing test, you take care that the test is minimal, but it fails for exactly the
                                                Message 23 of 30 , Dec 12, 2004
                                                • 0 Attachment
                                                  Gary F wrote:

                                                  > Other types of testing don't have the same benefit with regard to debugging that unit tests have.
                                                  > They certainly have other types of value, but unit tests provide a tremendous tool for isolating
                                                  > bugs.

                                                  TDD often goes a little farther, into preventing bugs.

                                                  When you write a failing test, you take care that the test is minimal,
                                                  but it fails for exactly the correct reason.

                                                  When you make the test pass, you are allowed to lie. Returning to a
                                                  green bar is more important than making the code honest. This implies
                                                  one often takes more care to ensure a test fails for the correct
                                                  reason than one takes to make the test pass!

                                                  If you know the code lies, you must write more tests that expose the
                                                  lie. When these tests get their green bar, you are free to refactor
                                                  the code. Minimizing it and resolving duplication overwhelmingly
                                                  crushes out opportunities for bugs. The leanest code that fits a set
                                                  of tests has no room for bugs.

                                                  One practices the technique of using tests to force out temporary
                                                  lies, even when you don't know the code lies.

                                                  In greenfield projects, when adding logic-driven features, this form
                                                  of TDD rapidly drives code into a rock-solid situation with
                                                  vanishingly small chances of bugs.

                                                  --
                                                  Phlip
                                                • Todd Hartle
                                                  The tests are not part of the code, they are written test plan/cases that someone can follow or that can be automated via winrunner or the like.
                                                  Message 24 of 30 , Dec 13, 2004
                                                  • 0 Attachment
                                                    The tests are not part of the code, they are written test plan/cases
                                                    that someone can follow or that can be automated via winrunner or the
                                                    like.


                                                    On Sun, 12 Dec 2004 21:09:06 -0800 (PST), Gary F <gfyho@...> wrote:
                                                    >
                                                    > --- Todd Hartle <thartle@...> wrote:
                                                    >
                                                    > >
                                                    > > However, not unit testing does not imply not testing all. And it also
                                                    > > seems that unit testing can still exist even though the tests do not
                                                    > > live in the code.
                                                    >
                                                    > Other types of testing don't have the same benefit with regard to debugging
                                                    > that unit tests have.
                                                    > They certainly have other types of value, but unit tests provide a
                                                    > tremendous tool for isolating
                                                    > bugs.
                                                    >
                                                    > I'm not sure what you mean by "tests do not live in the code." Could you
                                                    > rephrase that, please?
                                                    >
                                                    > Gary
                                                    >
                                                    >
                                                    > __________________________________________________
                                                    > Do You Yahoo!?
                                                    > Tired of spam? Yahoo! Mail has the best spam protection around
                                                    > http://mail.yahoo.com
                                                    >
                                                    >
                                                    >
                                                    >
                                                    > To Post a message, send it to: scrumdevelopment@...
                                                    > To Unsubscribe, send a blank message to:
                                                    > scrumdevelopment-unsubscribe@...
                                                    >
                                                    >
                                                    >
                                                    > Yahoo! Groups Sponsor
                                                    >
                                                    > ADVERTISEMENT
                                                    >
                                                    >
                                                    > ________________________________
                                                    > Yahoo! Groups Links
                                                    >
                                                    > To visit your group on the web, go to:
                                                    > http://groups.yahoo.com/group/scrumdevelopment/
                                                    >
                                                    > To unsubscribe from this group, send an email to:
                                                    > scrumdevelopment-unsubscribe@yahoogroups.com
                                                    >
                                                    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                                  • Phlip
                                                    ... That s the traditional way to do it. The first layer of tests must be written by developers, in the same language as the source, and at the same time as
                                                    Message 25 of 30 , Dec 13, 2004
                                                    • 0 Attachment
                                                      Todd Hartle wrote:
                                                      >
                                                      > The tests are not part of the code, they are written test plan/cases
                                                      > that someone can follow or that can be automated via winrunner or the
                                                      > like.

                                                      That's the "traditional" way to do it.

                                                      The first layer of tests must be written by developers, in the same
                                                      language as the source, and at the same time as the features they
                                                      test.

                                                      That will provide enough decoupling and infrastructure to then write
                                                      "acceptance tests", using essentially an alternative program user
                                                      interface.

                                                      Testing thru a GUI adds a lot of burden, reducing the value of the
                                                      tests, and reducing the turnaround on feedback from decisions.

                                                      --
                                                      Phlip
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.