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

Re: [XP] Metrics from our project.

Expand Messages
  • Kevin Smith
    ... Absolutely fascinating. Your 50/50 mix of production code and unit tests seems about right to me. My current hobby project has about 60/40 production/test,
    Message 1 of 24 , Oct 1, 2000
    • 0 Attachment
      On 30 Sep 2000, at 13:05, Bob Whiteside wrote:

      > Hi All,
      >
      > I thought I'd share what we've been doing with metrics. We're a
      > team of three who just completed our second iteration (7 weeks total)
      > of a project following an XP-ish process. A distributed team of three
      > is tough to do XP with, but we're trying to modify process to make up
      > for practices we can't easily follow. Anyway, we've for a while had a
      > "nightly metrics" cron job running in the middle of the night. Here's
      > last night's report:
      >
      > ------------------------------
      > Unit tests: 206
      > Java source files: 135
      > Java classes: 157
      > Java total source lines: 14645
      > Java unit-test source lines: 7034
      > Java non-test lines: 7611
      > Total code lines analyzed: 2031
      > Unexecuted lines: 128
      > Test coverage: 93.70%
      > Passing functional tests: 113
      > Failing functional tests: 1
      > Skipped functional tests: 0
      > Uses of "instanceof": 12
      > Files modified by indenting: 0
      >
      > These files were modified:
      >
      > ------------------------------
      >
      > It starts with an empty directory, checks out top copy, builds and
      > runs tests, in addition to counting stuff.
      >
      > Now, lots of things we're measuring ... well ... just because they're
      > easy to measure. There's not necessarily any implication that we're
      > trying to maximize or minimize any particular number. Yes, I know the
      > joke about the drunk looking for his wallet underneath the
      > streetlight.
      >
      > Anyway, there are several things that I, at least, find interesting.
      >
      > First, about half the code we've written is unit test. Is this
      > typical?
      >
      > Near the end of iteration 1, one of our team members, Ernest
      > Friedman-Hill wrote us a code coverage tool. (He's the guy on the
      > team holding the Java pebble I keep trying to snatch.) Before he got
      > it running, we both guessed what the percent covered would be. He
      > guessed 60%, which is typical of results across many projects, I
      > think. I thought we were doing better than average, so guessed 80%
      > (expecting to be disappointed). We were both quite surprised at the
      > nearly 94% number.
      >
      > The unexecuted lines were almost all "throw" statements and "catch"
      > blocks. Some of these are things we should test (i.e., the user could
      > cause by typing the wrong thing). Others are things we're not likely
      > to ever unit-test, I'd guess: IO exceptions from disk full, or
      > whatever.
      >
      > Another really interesting number which we got as a side effect of the
      > coverage tool is the "Total code lines analyzed". This is the number
      > of production Java lines that actually have executable code on them.
      > This excludes comments and blank lines, of course, but also excludes
      > other things:
      >
      > - try {
      > - }
      > - I think it excludes declarations without initializers, but I'm not
      > sure.
      > - Method headers (I think).
      >
      > Anyway, it generally excludes Java source lines that don't result in a
      > bytecode being written into the classfile.
      >
      > So, looking at that number (about 2000): We've got about 14K total,
      > half of which is unit test. Of the 7 thousand lines of production
      > Java, only 2K of them actually execute anything!
      >
      > And, no, we don't have a very verbose coding style. 6-line file
      > headers. Modest comments (we try to write glaringly
      > obvious code). We put closing curly braces on a line of their own, but
      > the opening brace goes at the end of a line that opened the block.
      > If anything, we'll get more verbose. We could use some more javadocs,
      > for example.
      >
      > Anyway, I was surprised by this number.
      >
      > Hope this is interesting...

      Absolutely fascinating.

      Your 50/50 mix of production code and unit tests seems about right
      to me. My current hobby project has about 60/40 production/test,
      and I know I could use a few more tests.

      I'm a bit surprised by the 2/7 ratio of executing lines, but I would
      guess my code would come in around 3/7 or 4/7, so it's not that far
      off. Little methods really affect this, obviously.

      Thanks for sharing!

      Kevin
    • RICK KARCICH
      How many bugs/faults/defects were found? Rick
      Message 2 of 24 , Oct 1, 2000
      • 0 Attachment
        How many bugs/faults/defects were found?

        Rick

        Kevin Smith wrote:
        >
        > On 30 Sep 2000, at 13:05, Bob Whiteside wrote:
        >
        > > Hi All,
        > >
        > > I thought I'd share what we've been doing with metrics. We're a
        > > team of three who just completed our second iteration (7 weeks total)
        > > of a project following an XP-ish process. A distributed team of three
        > > is tough to do XP with, but we're trying to modify process to make up
        > > for practices we can't easily follow. Anyway, we've for a while had a
        > > "nightly metrics" cron job running in the middle of the night. Here's
        > > last night's report:
        > >
        > > ------------------------------
        > > Unit tests: 206
        > > Java source files: 135
        > > Java classes: 157
        > > Java total source lines: 14645
        > > Java unit-test source lines: 7034
        > > Java non-test lines: 7611
        > > Total code lines analyzed: 2031
        > > Unexecuted lines: 128
        > > Test coverage: 93.70%
        > > Passing functional tests: 113
        > > Failing functional tests: 1
        > > Skipped functional tests: 0
        > > Uses of "instanceof": 12
        > > Files modified by indenting: 0
        > >
        > > These files were modified:
        > >
        > > ------------------------------
        > >
        > > It starts with an empty directory, checks out top copy, builds and
        > > runs tests, in addition to counting stuff.
        > >
        > > Now, lots of things we're measuring ... well ... just because they're
        > > easy to measure. There's not necessarily any implication that we're
        > > trying to maximize or minimize any particular number. Yes, I know the
        > > joke about the drunk looking for his wallet underneath the
        > > streetlight.
        > >
        > > Anyway, there are several things that I, at least, find interesting.
        > >
        > > First, about half the code we've written is unit test. Is this
        > > typical?
        > >
        > > Near the end of iteration 1, one of our team members, Ernest
        > > Friedman-Hill wrote us a code coverage tool. (He's the guy on the
        > > team holding the Java pebble I keep trying to snatch.) Before he got
        > > it running, we both guessed what the percent covered would be. He
        > > guessed 60%, which is typical of results across many projects, I
        > > think. I thought we were doing better than average, so guessed 80%
        > > (expecting to be disappointed). We were both quite surprised at the
        > > nearly 94% number.
        > >
        > > The unexecuted lines were almost all "throw" statements and "catch"
        > > blocks. Some of these are things we should test (i.e., the user could
        > > cause by typing the wrong thing). Others are things we're not likely
        > > to ever unit-test, I'd guess: IO exceptions from disk full, or
        > > whatever.
        > >
        > > Another really interesting number which we got as a side effect of the
        > > coverage tool is the "Total code lines analyzed". This is the number
        > > of production Java lines that actually have executable code on them.
        > > This excludes comments and blank lines, of course, but also excludes
        > > other things:
        > >
        > > - try {
        > > - }
        > > - I think it excludes declarations without initializers, but I'm not
        > > sure.
        > > - Method headers (I think).
        > >
        > > Anyway, it generally excludes Java source lines that don't result in a
        > > bytecode being written into the classfile.
        > >
        > > So, looking at that number (about 2000): We've got about 14K total,
        > > half of which is unit test. Of the 7 thousand lines of production
        > > Java, only 2K of them actually execute anything!
        > >
        > > And, no, we don't have a very verbose coding style. 6-line file
        > > headers. Modest comments (we try to write glaringly
        > > obvious code). We put closing curly braces on a line of their own, but
        > > the opening brace goes at the end of a line that opened the block.
        > > If anything, we'll get more verbose. We could use some more javadocs,
        > > for example.
        > >
        > > Anyway, I was surprised by this number.
        > >
        > > Hope this is interesting...
        >
        > Absolutely fascinating.
        >
        > Your 50/50 mix of production code and unit tests seems about right
        > to me. My current hobby project has about 60/40 production/test,
        > and I know I could use a few more tests.
        >
        > I'm a bit surprised by the 2/7 ratio of executing lines, but I would
        > guess my code would come in around 3/7 or 4/7, so it's not that far
        > off. Little methods really affect this, obviously.
        >
        > Thanks for sharing!
        >
        > Kevin
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        > Ad-free courtesy of objectmentor.com
      • David Vivash
        ... So is this a case of using XP for some design up front? Maybe not big design up front, but at least a little. Did you refactor any of the design (that
        Message 3 of 24 , Oct 2, 2000
        • 0 Attachment
          > I've used it in the actual implementation of a system. We have a
          > system that can accept requests from a number of clients. These
          > requests are broken down into smaller sized chunks of work, which need
          > to be done by specific servers in the system. Once the servers are
          > finished, the client needs to be updated with the progress of his
          > request.
          >
          > We implemented this in terms of a construction contractor. There is a
          > GeneralContractor, whose job is it to take the Jobs and divide them up
          > into smaller sized WorkOrders. Think of this as ordering a house, and
          > the GC splitting the job up into plumbing, electrical, etc jobs. These
          > work orders are posted onto a WorkOrderBoard, which SubContractors
          > pull off the board. This is done by finding the highest priority
          > WorkOrder which that SC is qualified to perform. Once a WorkOrder is
          > complete, its status is updated, and a CustomerAgent sends a progress
          > report to the original customer.
          >
          > These objects form the basis for our system.
          >
          > bab

          So is this a case of using XP for some design up front? Maybe not
          big design up front, but at least a little. Did you refactor any of the
          design (that you mentioned above) at any stage, or did you find
          that you refactored around it? (ie. used the metaphor for your
          framework, and bolted on refactored code around it)

          David
        • Brian Button
          ... Yes, we did some design up front on this project. Actually, it began with some brainstorming to see if we could find some metaphorical way to talk about
          Message 4 of 24 , Oct 2, 2000
          • 0 Attachment
            David Vivash wrote:
            >
            > > These objects form the basis for our system.

            > So is this a case of using XP for some design up front? Maybe not
            > big design up front, but at least a little. Did you refactor any of the
            > design (that you mentioned above) at any stage, or did you find
            > that you refactored around it? (ie. used the metaphor for your
            > framework, and bolted on refactored code around it)

            Yes, we did some design up front on this project. Actually, it began
            with some brainstorming to see if we could find some metaphorical way
            to talk about the system, and we eventually came up with this -- it
            only took about 15 minutes or so. Then we did try throwing some
            scenarios at it to see if the metaphor would actually hold up in real
            use, and it did. Now, when we start looking at stories, we model it
            first in terms of the metaphor and then break it down into tasks. Bear
            in mind that we don't take a lot of time doing this, only about 1/2
            day or so for all the stories in an iteration. Then the code is
            written around the metaphor.

            I do think that we are lucky that we have this good metaphor, as I
            think it would be a lot harder to make progress on a system without
            having this basic, architectural/metaphorical framework in place. We
            are open to changes in it, though :)

            bab

            --
            Brian Button bbutton@...
            Senior Consultant Object Mentor, Inc.
          • Crocker Ron-QA1007
            This is one of those areas that blurs the distinction between something like FDD and XP. I believe that having a metaphor is important for XP to work. It s the
            Message 5 of 24 , Oct 2, 2000
            • 0 Attachment
              This is one of those areas that blurs the distinction between something like
              FDD and XP. I believe that having a metaphor is important for XP to work.
              It's the constant, the guiding light that you look at when you're confused.

              As for level of metaphor, that depends. For my team, we had one that was
              really high level but provided the guidance for deciding where to put some
              responsiblity. We had another one at a more detailed level that I've
              described in previous notes as "weird paint by numbers." It was a sketch of
              an static object diagram, but it changed over time. FDD seems to imply that
              it is all worked out, then you just build what you worked out. Our paint by
              numbers metaphor also was at a higher level than objects, say little
              federations of objects, and the federations interacted to provide the
              service.

              Ron

              > -----Original Message-----
              > From: Brian Button [mailto:bbutton@...]
              > Sent: Monday, October 02, 2000 10:14 AM
              > To: extremeprogramming@egroups.com
              > Subject: Re: [XP] System metaphor
              >
              >
              > David Vivash wrote:
              > >
              > > > These objects form the basis for our system.
              >
              > > So is this a case of using XP for some design up front? Maybe not
              > > big design up front, but at least a little. Did you
              > refactor any of the
              > > design (that you mentioned above) at any stage, or did you find
              > > that you refactored around it? (ie. used the metaphor for your
              > > framework, and bolted on refactored code around it)
              >
              > Yes, we did some design up front on this project. Actually, it began
              > with some brainstorming to see if we could find some metaphorical way
              > to talk about the system, and we eventually came up with this -- it
              > only took about 15 minutes or so. Then we did try throwing some
              > scenarios at it to see if the metaphor would actually hold up in real
              > use, and it did. Now, when we start looking at stories, we model it
              > first in terms of the metaphor and then break it down into tasks. Bear
              > in mind that we don't take a lot of time doing this, only about 1/2
              > day or so for all the stories in an iteration. Then the code is
              > written around the metaphor.
              >
              > I do think that we are lucky that we have this good metaphor, as I
              > think it would be a lot harder to make progress on a system without
              > having this basic, architectural/metaphorical framework in place. We
              > are open to changes in it, though :)
              >
              > bab
              >
              > --
              > Brian Button bbutton@...
              > Senior Consultant Object Mentor, Inc.
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > Ad-free courtesy of objectmentor.com
              >
            • Glen Stampoultzis
              ... got ... Nice work. Anyone know of a free Java code coverage tool that can be driven from the command line? It would be nice to integrate this into our
              Message 6 of 24 , Oct 2, 2000
              • 0 Attachment
                > Near the end of iteration 1, one of our team members, Ernest
                > Friedman-Hill wrote us a code coverage tool. (He's the guy on the
                > team holding the Java pebble I keep trying to snatch.) Before he
                got
                > it running, we both guessed what the percent covered would be. He
                > guessed 60%, which is typical of results across many projects, I
                > think. I thought we were doing better than average, so guessed 80%
                > (expecting to be disappointed). We were both quite surprised at the
                > nearly 94% number.

                Nice work. Anyone know of a free Java code coverage tool that can be
                driven from the command line? It would be nice to integrate this
                into our current automated build process.

                -- Glen Stampoultzis
              • ejfried@ca.sandia.gov
                Well, I d like to release ours. It s nothing fancy, but it works and the price is right. I need to confirm that it s OK to use the bytecode libs it uses in
                Message 7 of 24 , Oct 2, 2000
                • 0 Attachment
                  Well, I'd like to release ours. It's nothing fancy, but it works and
                  the price is right.

                  I need to confirm that it's OK to use the bytecode libs it uses in
                  open source software, and I need to do the organizational paperwork
                  here to release software to the public domain. I'll be sure to
                  announce it on this list when it is available.

                  I think Glen Stampoultzis wrote:
                  >
                  > Nice work. Anyone know of a free Java code coverage tool that can be
                  > driven from the command line? It would be nice to integrate this
                  > into our current automated build process.
                  >
                  > -- Glen Stampoultzis


                  ---------------------------------------------------------
                  Ernest Friedman-Hill
                  Distributed Systems Research Phone: (925) 294-2154
                  Sandia National Labs FAX: (925) 294-2234
                  Org. 8920, MS 9012 ejfried@...
                  PO Box 969 http://herzberg.ca.sandia.gov
                  Livermore, CA 94550
                • Bob Whiteside
                  Hi Rick, ... I really don t know how to answer that. We re a new project starting with a clean sheet of paper . Thus with test-first development, the unit
                  Message 8 of 24 , Oct 3, 2000
                  • 0 Attachment
                    Hi Rick,
                    >
                    >
                    > How many bugs/faults/defects were found?
                    >
                    I really don't know how to answer that. We're a new project starting
                    with a "clean sheet of paper". Thus with test-first development, the unit
                    tests kinda by definition found zero defects. We've never checked in code
                    that didn't pass all the unit tests. Functional tests, of course, fail
                    since they may test for features that are currently unimplmented.

                    We do have a "bugs.txt" file, however I'm not sure if we're gonna use even
                    that. The (few) things we've put into there were not generally bugs, but
                    rather issues resulting from ambiguities in the implemented stories. That
                    is, we implemented the story, then when we looked at the result, there was a
                    "Oh, it should really do *this*" kind of thing. For such issues that were
                    very small, we've put them into "bugs", mostly so we didn't forget them.
                    For larger things, we wrote a new story.

                    Cheers,
                    --Bob


                    > -----Original Message-----
                    > From: Richard.Karcich@...
                    > [mailto:Richard.Karcich@...]On Behalf Of RICK KARCICH
                    > Sent: October 01, 2000 2:58 PM
                    > To: extremeprogramming@egroups.com
                    > Subject: Re: [XP] Metrics from our project.
                    >
                    >
                    > How many bugs/faults/defects were found?
                    >
                    > Rick
                    >
                    > Kevin Smith wrote:
                    > >
                    > > On 30 Sep 2000, at 13:05, Bob Whiteside wrote:
                    > >
                    > > > Hi All,
                    > > >
                    > > > I thought I'd share what we've been doing with
                    > metrics. We're a
                    > > > team of three who just completed our second iteration (7
                    > weeks total)
                    > > > of a project following an XP-ish process. A distributed
                    > team of three
                    > > > is tough to do XP with, but we're trying to modify
                    > process to make up
                    > > > for practices we can't easily follow. Anyway, we've for
                    > a while had a
                    > > > "nightly metrics" cron job running in the middle of the
                    > night. Here's
                    > > > last night's report:
                    > > >
                    > > > ------------------------------
                    > > > Unit tests: 206
                    > > > Java source files: 135
                    > > > Java classes: 157
                    > > > Java total source lines: 14645
                    > > > Java unit-test source lines: 7034
                    > > > Java non-test lines: 7611
                    > > > Total code lines analyzed: 2031
                    > > > Unexecuted lines: 128
                    > > > Test coverage: 93.70%
                    > > > Passing functional tests: 113
                    > > > Failing functional tests: 1
                    > > > Skipped functional tests: 0
                    > > > Uses of "instanceof": 12
                    > > > Files modified by indenting: 0
                    > > >
                    > > > These files were modified:
                    > > >
                    > > > ------------------------------
                    > > >
                    > > > It starts with an empty directory, checks out top copy, builds and
                    > > > runs tests, in addition to counting stuff.
                    > > >
                    > > > Now, lots of things we're measuring ... well ... just
                    > because they're
                    > > > easy to measure. There's not necessarily any implication
                    > that we're
                    > > > trying to maximize or minimize any particular number.
                    > Yes, I know the
                    > > > joke about the drunk looking for his wallet underneath the
                    > > > streetlight.
                    > > >
                    > > > Anyway, there are several things that I, at least, find
                    > interesting.
                    > > >
                    > > > First, about half the code we've written is unit test. Is this
                    > > > typical?
                    > > >
                    > > > Near the end of iteration 1, one of our team members, Ernest
                    > > > Friedman-Hill wrote us a code coverage tool. (He's the guy on the
                    > > > team holding the Java pebble I keep trying to snatch.)
                    > Before he got
                    > > > it running, we both guessed what the percent covered would be. He
                    > > > guessed 60%, which is typical of results across many projects, I
                    > > > think. I thought we were doing better than average, so
                    > guessed 80%
                    > > > (expecting to be disappointed). We were both quite
                    > surprised at the
                    > > > nearly 94% number.
                    > > >
                    > > > The unexecuted lines were almost all "throw" statements
                    > and "catch"
                    > > > blocks. Some of these are things we should test (i.e.,
                    > the user could
                    > > > cause by typing the wrong thing). Others are things
                    > we're not likely
                    > > > to ever unit-test, I'd guess: IO exceptions from disk full, or
                    > > > whatever.
                    > > >
                    > > > Another really interesting number which we got as a side
                    > effect of the
                    > > > coverage tool is the "Total code lines analyzed". This
                    > is the number
                    > > > of production Java lines that actually have executable
                    > code on them.
                    > > > This excludes comments and blank lines, of course, but
                    > also excludes
                    > > > other things:
                    > > >
                    > > > - try {
                    > > > - }
                    > > > - I think it excludes declarations without initializers,
                    > but I'm not
                    > > > sure.
                    > > > - Method headers (I think).
                    > > >
                    > > > Anyway, it generally excludes Java source lines that
                    > don't result in a
                    > > > bytecode being written into the classfile.
                    > > >
                    > > > So, looking at that number (about 2000): We've got about
                    > 14K total,
                    > > > half of which is unit test. Of the 7 thousand lines of production
                    > > > Java, only 2K of them actually execute anything!
                    > > >
                    > > > And, no, we don't have a very verbose coding style. 6-line file
                    > > > headers. Modest comments (we try to write glaringly
                    > > > obvious code). We put closing curly braces on a line of
                    > their own, but
                    > > > the opening brace goes at the end of a line that opened the block.
                    > > > If anything, we'll get more verbose. We could use some
                    > more javadocs,
                    > > > for example.
                    > > >
                    > > > Anyway, I was surprised by this number.
                    > > >
                    > > > Hope this is interesting...
                    > >
                    > > Absolutely fascinating.
                    > >
                    > > Your 50/50 mix of production code and unit tests seems about right
                    > > to me. My current hobby project has about 60/40 production/test,
                    > > and I know I could use a few more tests.
                    > >
                    > > I'm a bit surprised by the 2/7 ratio of executing lines, but I would
                    > > guess my code would come in around 3/7 or 4/7, so it's not that far
                    > > off. Little methods really affect this, obviously.
                    > >
                    > > Thanks for sharing!
                    > >
                    > > Kevin
                    > >
                    > > To Post a message, send it to: extremeprogramming@...
                    > >
                    > > To Unsubscribe, send a blank message to:
                    > extremeprogramming-unsubscribe@...
                    > >
                    > > Ad-free courtesy of objectmentor.com
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to:
                    > extremeprogramming-unsubscribe@...
                    >
                    > Ad-free courtesy of objectmentor.com
                    >
                  • Kent Beck
                    Nice work. Anyone know of a free Java code coverage tool that can be driven from the command line? It would be nice to integrate this into our current
                    Message 9 of 24 , Oct 3, 2000
                    • 0 Attachment
                      "Nice work. Anyone know of a free Java code coverage tool that can be
                      driven from the command line? It would be nice to integrate this
                      into our current automated build process."

                      Better yet, can someone turn this into a server so I can upload my jar file
                      periodically and see how I rank compared to other projects, as well as how I
                      progress over time?

                      Kent
                    • C & C Helck
                      Why do you count instances of instanceOf ? Any ideas what a high number would mean?
                      Message 10 of 24 , Oct 3, 2000
                      • 0 Attachment
                        Why do you count instances of "instanceOf"? Any ideas what a high number
                        would mean?

                        At 01:05 PM 9/30/00 -0700, you wrote:
                        >Hi All,
                        >
                        > I thought I'd share what we've been doing with metrics. We're a
                        >team of three who just completed our second iteration (7 weeks total)
                        >of a project following an XP-ish process. A distributed team of three
                        >is tough to do XP with, but we're trying to modify process to make up
                        >for practices we can't easily follow. Anyway, we've for a while had a
                        >"nightly metrics" cron job running in the middle of the night. Here's
                        >last night's report:
                        >
                        >------------------------------
                        >Unit tests: 206
                        >Java source files: 135
                        >Java classes: 157
                        >Java total source lines: 14645
                        >Java unit-test source lines: 7034
                        >Java non-test lines: 7611
                        >Total code lines analyzed: 2031
                        >Unexecuted lines: 128
                        >Test coverage: 93.70%
                        >Passing functional tests: 113
                        >Failing functional tests: 1
                        >Skipped functional tests: 0
                        >Uses of "instanceof": 12
                        >Files modified by indenting: 0
                        >
                        >These files were modified:
                        >
                        >------------------------------
                        >
                        >It starts with an empty directory, checks out top copy, builds and
                        >runs tests, in addition to counting stuff.
                        >
                        >Now, lots of things we're measuring ... well ... just because they're
                        >easy to measure. There's not necessarily any implication that we're
                        >trying to maximize or minimize any particular number. Yes, I know the
                        >joke about the drunk looking for his wallet underneath the
                        >streetlight.
                        >
                        >Anyway, there are several things that I, at least, find interesting.
                        >
                        >First, about half the code we've written is unit test. Is this
                        >typical?
                        >
                        >Near the end of iteration 1, one of our team members, Ernest
                        >Friedman-Hill wrote us a code coverage tool. (He's the guy on the
                        >team holding the Java pebble I keep trying to snatch.) Before he got
                        >it running, we both guessed what the percent covered would be. He
                        >guessed 60%, which is typical of results across many projects, I
                        >think. I thought we were doing better than average, so guessed 80%
                        >(expecting to be disappointed). We were both quite surprised at the
                        >nearly 94% number.
                        >
                        >The unexecuted lines were almost all "throw" statements and "catch"
                        >blocks. Some of these are things we should test (i.e., the user could
                        >cause by typing the wrong thing). Others are things we're not likely
                        >to ever unit-test, I'd guess: IO exceptions from disk full, or
                        >whatever.
                        >
                        >Another really interesting number which we got as a side effect of the
                        >coverage tool is the "Total code lines analyzed". This is the number
                        >of production Java lines that actually have executable code on them.
                        >This excludes comments and blank lines, of course, but also excludes
                        >other things:
                        >
                        > - try {
                        > - }
                        > - I think it excludes declarations without initializers, but I'm not
                        > sure.
                        > - Method headers (I think).
                        >
                        >Anyway, it generally excludes Java source lines that don't result in a
                        >bytecode being written into the classfile.
                        >
                        >So, looking at that number (about 2000): We've got about 14K total,
                        >half of which is unit test. Of the 7 thousand lines of production
                        >Java, only 2K of them actually execute anything!
                        >
                        >And, no, we don't have a very verbose coding style. 6-line file
                        >headers. Modest comments (we try to write glaringly
                        >obvious code). We put closing curly braces on a line of their own, but
                        >the opening brace goes at the end of a line that opened the block.
                        >If anything, we'll get more verbose. We could use some more javadocs,
                        >for example.
                        >
                        >Anyway, I was surprised by this number.
                        >
                        >Hope this is interesting...
                        >
                        >Cheers,
                        >--Bob
                        >
                        >
                        >To Post a message, send it to: extremeprogramming@...
                        >
                        >To Unsubscribe, send a blank message to:
                        >extremeprogramming-unsubscribe@...
                        >
                        >Ad-free courtesy of objectmentor.com
                      • Erik Meade
                        ... Certain uses of instanceOf ( like in if statements ) are a missed opportunities to use polymorphism. -- Erik Meade emeade@objectmentor.com
                        Message 11 of 24 , Oct 3, 2000
                        • 0 Attachment
                          > -----Original Message-----
                          > From: C & C Helck
                          > Sent: Tuesday, October 03, 2000 7:43 PM
                          > To: extremeprogramming@egroups.com
                          > Subject: Re: [XP] Metrics from our project.
                          >
                          >
                          > Why do you count instances of "instanceOf"? Any ideas what a high number
                          > would mean?
                          >

                          Certain uses of instanceOf ( like in if statements ) are a missed
                          opportunities to use polymorphism.

                          --
                          Erik Meade emeade@...
                          Senior Consultant Object Mentor, Inc.
                        • Ron Jeffries
                          ... Bad design practice. Shouldn t ask an object what it is, should just send it a standard message to which it responds properly. Lots of instanceOf s are a
                          Message 12 of 24 , Oct 3, 2000
                          • 0 Attachment
                            At 10:42 PM 10/3/2000 -0400, C & C Helck wrote:
                            >Why do you count instances of "instanceOf"? Any ideas what a high number
                            >would mean?

                            Bad design practice. Shouldn't ask an object what it is, should just send
                            it a standard message to which it responds properly. Lots of instanceOf's
                            are a bad smell.



                            Ron Jeffries
                            www.XProgramming.com
                            www.objectmentor.com
                          • Robert Watkins
                            ... Stuff like this is definitely bad: if (aObject instanceof ClassA) { ((ClassA)aObject).aMessage(); } else if (aObject instanceof ClassB) {
                            Message 13 of 24 , Oct 3, 2000
                            • 0 Attachment
                              Erik Meade writes:
                              > > Why do you count instances of "instanceOf"? Any ideas what a
                              > high number
                              > > would mean?
                              > >
                              >
                              > Certain uses of instanceOf ( like in if statements ) are a missed
                              > opportunities to use polymorphism.

                              Stuff like this is definitely bad:

                              if (aObject instanceof ClassA) {
                              ((ClassA)aObject).aMessage();
                              }
                              else if (aObject instanceof ClassB) {
                              ((ClassB)aObject).aDifferentMessage();
                              }

                              Assuming you've got control of both ClassA and ClassB, you should be using
                              polymorphism. If you don't have control, you should be using a wrapper class
                              and polymorphism.

                              But use of instanceof like this is, IMHO, an okay thing:

                              public void doSomething(Object aObject) {
                              if (aObject instanceof ClassA) {
                              ((ClassA)aObject).aMessage();
                              }
                              else {
                              throw new MoreMeaningfulExceptionThanClassCastException("You gave me the
                              wrong type of object");
                              }
                              }


                              Now, this probably isn't the best type of thing, either... But there are
                              valid reasons to be passing Objects around, and having to cast them
                              downwards (and I'm not even talking about collections, here).

                              Robert.

                              --
                              /\\\ Robert Watkins | Email: robert.watkins@...
                              ( ))) Software Engineer - Tech Dev | Ph: +61 7 3303 3432
                              \/// MINCOM Ltd | Fax: +61 7 3303 3232
                              Mincom

                              This transmission is for the intended addressee only and is confidential
                              information. If you have received this transmission in error, please
                              delete it and notify the sender. The contents of this e-mail are the
                              opinion of the writer only and are not endorsed by Mincom Limited unless
                              expressly stated otherwise.
                            • Bob Whiteside
                              Hi C&C! Ya, as others have mentioned, we track it just as a code smell. We dont forbid them, but each such use represents, in some sense, an object-oriented
                              Message 14 of 24 , Oct 4, 2000
                              • 0 Attachment
                                Hi C&C!

                                Ya, as others have mentioned, we track it just as a code smell. We dont'
                                forbid them, but each such use represents, in some sense, an object-oriented
                                failure.

                                We use Visitor to demultiplex our main structures, but "instanceOf" is very
                                tempting in other cases. I guess the metric is just to see how often we're
                                resisting the temptation.

                                Cheers,
                                --Bob


                                > -----Original Message-----
                                > From: C & C Helck [mailto:pp002531@...]
                                > Sent: October 03, 2000 7:43 PM
                                > To: extremeprogramming@egroups.com
                                > Subject: Re: [XP] Metrics from our project.
                                >
                                >
                                > Why do you count instances of "instanceOf"? Any ideas what a
                                > high number
                                > would mean?
                                >
                              • Johannes Brodwall
                                From: Robert Watkins ... If you think this is bad, try the following: if (aObject instanceof ClassA) {
                                Message 15 of 24 , Oct 8, 2000
                                • 0 Attachment
                                  From: "Robert Watkins" <robert.watkins@...>
                                  >
                                  > Stuff like this is definitely bad:
                                  >
                                  > if (aObject instanceof ClassA) {
                                  > ((ClassA)aObject).aMessage();
                                  > }
                                  > else if (aObject instanceof ClassB) {
                                  > ((ClassB)aObject).aDifferentMessage();
                                  > }
                                  >


                                  If you think this is bad, try the following:

                                  if (aObject instanceof ClassA) {
                                  ((ClassA)aObject).aMessage();
                                  } else if (aObject instanceof ClassB) {
                                  ((ClassB)aObject).aMessage();
                                  }

                                  Yes, the classes have the same message, but no common superclass with this
                                  message. *sigh* The things we put ourselves through for money (and love, I
                                  guess) ;-/


                                  ~j'hannes
                                • Eric Hodges
                                  ... From: Johannes Brodwall To: Sent: Sunday, October 08, 2000 10:20 AM Subject: Re: [XP] Metrics from
                                  Message 16 of 24 , Oct 9, 2000
                                  • 0 Attachment
                                    ----- Original Message -----
                                    From: "Johannes Brodwall" <brodwall@...>
                                    To: <extremeprogramming@egroups.com>
                                    Sent: Sunday, October 08, 2000 10:20 AM
                                    Subject: Re: [XP] Metrics from our project.


                                    > If you think this is bad, try the following:
                                    >
                                    > if (aObject instanceof ClassA) {
                                    > ((ClassA)aObject).aMessage();
                                    > } else if (aObject instanceof ClassB) {
                                    > ((ClassB)aObject).aMessage();
                                    > }
                                    >
                                    > Yes, the classes have the same message, but no common superclass with this
                                    > message. *sigh* The things we put ourselves through for money (and love,
                                    I
                                    > guess) ;-/

                                    Sounds like a good time to create an interface.
                                  • Johannes Brodwall
                                    From: Eric Hodges ... this ... love, I ... As soon as I get my dirty paws on the code, that is exactly what I am planning to do. Being
                                    Message 17 of 24 , Oct 9, 2000
                                    • 0 Attachment
                                      From: "Eric Hodges" <harmony2@...>
                                      >
                                      > From: "Johannes Brodwall" <brodwall@...>
                                      >
                                      > > If you think this is bad, try the following:
                                      > >
                                      > > if (aObject instanceof ClassA) {
                                      > > ((ClassA)aObject).aMessage();
                                      > > } else if (aObject instanceof ClassB) {
                                      > > ((ClassB)aObject).aMessage();
                                      > > }
                                      > >
                                      > > Yes, the classes have the same message, but no common superclass with
                                      this
                                      > > message. *sigh* The things we put ourselves through for money (and
                                      love, I
                                      > > guess) ;-/
                                      >
                                      > Sounds like a good time to create an interface.

                                      As soon as I get my dirty paws on the code, that is exactly what I am
                                      planning to do. Being new in this project, though, I prefer to start with a
                                      somewhat low profile. <music type="eerie">Time is not yet right, the stars
                                      are not in constellation.</music>

                                      Does anyone have any experience with getting thrown into a large development
                                      project with large amounts of poor code, only a little of which is under
                                      your control? Luckily, the mental environment is quite open to new ideas,
                                      while not being prone to throw itself blindly on any bandwagon that comes
                                      along.

                                      ~j'hannes
                                    • bubba99@mindspring.com
                                      ... am ... start with a ... the stars ... development ... under ... ideas, ... comes ... A little. Oh, I suppose I should be introductive -- My name s Bubba
                                      Message 18 of 24 , Oct 10, 2000
                                      • 0 Attachment
                                        --- In extremeprogramming@egroups.com, "Johannes Brodwall"
                                        <brodwall@s...> wrote:
                                        > > Sounds like a good time to create an interface.
                                        >
                                        > As soon as I get my dirty paws on the code, that is exactly what I
                                        am
                                        > planning to do. Being new in this project, though, I prefer to
                                        start with a
                                        > somewhat low profile. <music type="eerie">Time is not yet right,
                                        the stars
                                        > are not in constellation.</music>
                                        >
                                        > Does anyone have any experience with getting thrown into a large
                                        development
                                        > project with large amounts of poor code, only a little of which is
                                        under
                                        > your control? Luckily, the mental environment is quite open to new
                                        ideas,
                                        > while not being prone to throw itself blindly on any bandwagon that
                                        comes
                                        > along.
                                        >
                                        > ~j'hannes

                                        A little.

                                        Oh, I suppose I should be introductive -- My name's Bubba Puryear and
                                        I live in the Triangle area of NC. I've been reading about XP for a
                                        few months now and have watched other people practice parts of it
                                        (pair programming in particular) and have done some test-first coding
                                        with JUnit. (loved it!) Anyhows:

                                        I took a job a couple months back with a company that has a rather
                                        large code base of exteremely fragile code that results in constant
                                        phone calls from the client about what's broken now and why it should
                                        already by fixed. (ala - Firefighing) Some of my higher-ups are open,
                                        too, and I was told I was being hired in part to contribute
                                        to "improving quality" - which encouraged me a lot at the time. Since
                                        then, though, I've been getting a fair amount of "yeah, but make the
                                        phone stop ringing -- we'll refactor it later". Personally, I'm
                                        leaning heavily in the direction of Fowler's "change your
                                        organization" mantra.... <so if anyone knows an XP team in or around
                                        Cary, NC... oh wait, there's an xp-jobs group isn't there...>

                                        But to address your question: If you get assignments to do new work
                                        or to work on lower-level components -- consider dropping jUnit in
                                        and doing some test-first coding. (I've sneaked it into projects
                                        before <g>)

                                        If you are comfortable with a co-worker's technical prowess who
                                        happens to be familiar with the assignment you've been given, you
                                        could possible subtly pull him/her in for some pair programming.

                                        If you are working on an assignment and your reaction is "this mess
                                        needs to be redone", try to re-design a limited scope (preferrably a
                                        lower-level component with not too many clients), making use of what
                                        aspects of XP you can. (if code ownership is the norm in your org,
                                        you can start cleaning the base you've been given control over and
                                        set an example for others... etc)

                                        But, I'd keep Martin's quote in mind if you find project inertia too
                                        great to overcome...

                                        My $0.02 and best luck,
                                        Bubba
                                      • Peter Schrier & Narda Bergsma
                                        Message 19 of 24 , Oct 11, 2000
                                        • 0 Attachment
                                          Quoting Johannes Brodwall <brodwall@...>:

                                          >
                                          > From: "Eric Hodges" <harmony2@...>
                                          > >
                                          > > From: "Johannes Brodwall" <brodwall@...>
                                          > >
                                          > > > If you think this is bad, try the following:
                                          > > >
                                          > > > if (aObject instanceof ClassA) {
                                          > > > ((ClassA)aObject).aMessage();
                                          > > > } else if (aObject instanceof ClassB) {
                                          > > > ((ClassB)aObject).aMessage();
                                          > > > }
                                          > > >
                                          > > > Yes, the classes have the same message, but no common superclass with
                                          > this
                                          > > > message. *sigh* The things we put ourselves through for money (and
                                          > love, I
                                          > > > guess) ;-/
                                          > >
                                          > > Sounds like a good time to create an interface.
                                          >
                                          > As soon as I get my dirty paws on the code, that is exactly what I am
                                          > planning to do. Being new in this project, though, I prefer to start with
                                          > a
                                          > somewhat low profile. <music type="eerie">Time is not yet right, the stars
                                          > are not in constellation.</music>
                                          >
                                          > Does anyone have any experience with getting thrown into a large
                                          > development
                                          > project with large amounts of poor code, only a little of which is under
                                          > your control? Luckily, the mental environment is quite open to new ideas,
                                          > while not being prone to throw itself blindly on any bandwagon that comes
                                          > along.
                                          >
                                          > ~j'hannes
                                          >
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          >
                                          > Ad-free courtesy of objectmentor.com
                                          >
                                          >
                                        • Peter Schrier
                                          Hi J hannes (first apologies for the previous emoty message. Hit the wrong button) yes, I have experience being thrown in a big environment with only a limited
                                          Message 20 of 24 , Oct 11, 2000
                                          • 0 Attachment
                                            Hi J'hannes
                                            (first apologies for the previous emoty message. Hit the wrong button)

                                            yes, I have experience being thrown in a big environment with only a limited
                                            part under your control (Non-OO although; F77 and F90, sigh).

                                            I started also with a low profile, while restructuring te code under my
                                            control. As my control became larger I spread the restucturing. I tried to
                                            avoid influencing the code outside my control.

                                            When others came to see to discuss their and my code I took the oportunity to
                                            guide the others in 'good practices' (like the XP-practices). Gradually it the
                                            code improved.


                                            Peter
                                            Quoting Johannes Brodwall <brodwall@...>:

                                            >
                                            > From: "Eric Hodges" <harmony2@...>
                                            > >
                                            > > From: "Johannes Brodwall" <brodwall@...>
                                            > >
                                            > > > If you think this is bad, try the following:
                                            > > >
                                            > > > if (aObject instanceof ClassA) {
                                            > > > ((ClassA)aObject).aMessage();
                                            > > > } else if (aObject instanceof ClassB) {
                                            > > > ((ClassB)aObject).aMessage();
                                            > > > }
                                            > > >
                                            > > > Yes, the classes have the same message, but no common superclass with
                                            > this
                                            > > > message. *sigh* The things we put ourselves through for money (and
                                            > love, I
                                            > > > guess) ;-/
                                            > >
                                            > > Sounds like a good time to create an interface.
                                            >
                                            > As soon as I get my dirty paws on the code, that is exactly what I am
                                            > planning to do. Being new in this project, though, I prefer to start with
                                            > a
                                            > somewhat low profile. <music type="eerie">Time is not yet right, the stars
                                            > are not in constellation.</music>
                                            >
                                            > Does anyone have any experience with getting thrown into a large
                                            > development
                                            > project with large amounts of poor code, only a little of which is under
                                            > your control? Luckily, the mental environment is quite open to new ideas,
                                            > while not being prone to throw itself blindly on any bandwagon that comes
                                            > along.
                                            >
                                            > ~j'hannes
                                            >
                                            >
                                            > To Post a message, send it to: extremeprogramming@...
                                            >
                                            > To Unsubscribe, send a blank message to:
                                            > extremeprogramming-unsubscribe@...
                                            >
                                            > Ad-free courtesy of objectmentor.com
                                            >
                                            >
                                          Your message has been successfully submitted and would be delivered to recipients shortly.