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

Re: [XP] Agile toolset questions (particularly code inspections....)

Expand Messages
  • Ron Jeffries
    Hello, Craig. On Tuesday, December 2, 2008, at 8:47:20 AM, you ... Isn t code inspection a human process, not a tool process? Ron Jeffries
    Message 1 of 13 , Dec 2, 2008
    • 0 Attachment
      Hello, Craig. On Tuesday, December 2, 2008, at 8:47:20 AM, you
      wrote:

      > lol... Good point - my mistake. Sorry. So *other* than pair
      > programming, does anyone have any suggestions on what tools they've used?

      Isn't code inspection a human process, not a tool process?

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Think! -- Aretha Franklin
    • Steven Gordon
      ... I believe that process change and augmentation (including the introduction of new tools) should be driven by the problems currently being experiences. Why
      Message 2 of 13 , Dec 2, 2008
      • 0 Attachment
        On Tue, Dec 2, 2008 at 6:47 AM, Craig A <tabmow99@...> wrote:
        > lol... Good point - my mistake. Sorry. So *other* than pair
        > programming, does anyone have any suggestions on what tools they've used?

        I believe that process change and augmentation (including the
        introduction of new tools) should be driven by the problems currently
        being experiences. Why waste time and effort (and possibly disrupt a
        good rhythm) to fix something that is not even broken? So, what code
        quality problems is your team experiencing?

        What does the team believe the root causes of these specific problems
        are? Was the problematic code written by pair programming doing test
        driven development? If not, why not apply those practices before
        looking to a tool to be a silver bullet? If so, was it always a
        single pair that worked on each problematic section code? If not, why
        not try switching pairs more often? Was YAGNI followed? Was
        refactoring done on every TDD cycle?

        Only if after root cause analysis does the team honestly believe they
        are following the practices as well as they can should they look to a
        tool to help (unless the team believes the tool is essential for doing
        root cause analysis).

        Steven Gordon
      • Craig A
        It is a human process, and we do have automated tools doing static analysis, but using a tool helps facilitate the human process of doing quick code
        Message 3 of 13 , Dec 2, 2008
        • 0 Attachment
          It is a human process, and we do have automated tools doing static analysis,
          but using a tool helps facilitate the human process of doing quick code
          inspections. A good tool doesn't have to introduce a lot of overhead.


          >
          > Isn't code inspection a human process, not a tool process?
          >
          > Ron Jeffries
          > www.XProgramming.com
          > www.xprogramming.com/blog
          > Think! -- Aretha Franklin
          >
          >
          >


          [Non-text portions of this message have been removed]
        • agileprog
          Again, not a tool but human process. How about setting up a coding Dojo in your team/company? This provides the settings for sharing the know-how and
          Message 4 of 13 , Dec 2, 2008
          • 0 Attachment
            Again, not a tool but human process. How about setting up a coding
            Dojo in your team/company? This provides the settings for sharing the
            know-how and discussing code quality in a relaxed (in the sense of:
            not related to an actual project) environment.

            http://www.codingdojo.org



            --- In extremeprogramming@yahoogroups.com, "Craig A" <tabmow99@...> wrote:
            >
            > lol... Good point - my mistake. Sorry. So *other* than pair
            > programming, does anyone have any suggestions on what tools they've
            used?
            >
            >
            > On Mon, Dec 1, 2008 at 11:49 PM, Adam Sroka <adam.sroka@...> wrote:
            >
            > > Uh... you CC'd the XP list. So, Pair Programming.
            > >
            > >
            > > On Mon, Dec 1, 2008 at 7:40 PM, Craig A
            <tabmow99@...<tabmow99%40gmail.com>>
            > > wrote:
            > > > Hi all,
            > > > We've been using scrum for a while now, and are investigating a few
            > > > different toolsets to solve some of the things we wanted
            addressed. One
            > > > toolset we've been looking at is the Atlassian toolset (ie. JIRA
            > > > w/Greenhopper for story management/etc, Confluence, Crucible,
            etc) and
            > > I'm
            > > > really liking using Crucible for code inspections. However, it
            has a few
            > > > shortcomings that won't be addressed in the short term, so I was
            just
            > > > wondering what types of toolsets (or more specifically: what
            tool for
            > > code
            > > > inspections) other folks were using out there?
            > > >
            > > > Thanks,
            > > > Craig.
            > > >
            > > > [Non-text portions of this message have been removed]
            > > >
            > > >
            > >
            > >
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • Bill Michell
            For Java, I use Findbugs. Might not be quite what you re after, but as a free tool for static code analysis with good Eclipse and Ant integration, it is great.
            Message 5 of 13 , Dec 3, 2008
            • 0 Attachment
              For Java, I use Findbugs. Might not be quite what you're after, but as a
              free tool for static code analysis with good Eclipse and Ant
              integration, it is great.

              Occasional false positives, but it was Findbugs that got me to research
              why the double-checked locking idiom for lazy instantiation was a bad
              idea...

              Just like pairing with the combined wisdom of thousands of experts, all
              the time.


              --
              Bill Michell
              Development Team Leader, Broadcast Platforms, BBC FM&T (Journalism).

              -----Original Message-----
              From: extremeprogramming@yahoogroups.com
              [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Craig A
              Sent: 02 December 2008 13:47
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [XP] Agile toolset questions (particularly code
              inspections....)

              lol... Good point - my mistake. Sorry. So *other* than pair
              programming, does anyone have any suggestions on what tools they've
              used?


              On Mon, Dec 1, 2008 at 11:49 PM, Adam Sroka <adam.sroka@...>
              wrote:

              > Uh... you CC'd the XP list. So, Pair Programming.
              >
              >
              > On Mon, Dec 1, 2008 at 7:40 PM, Craig A
              <tabmow99@...<tabmow99%40gmail.com>>
              > wrote:
              > > Hi all,
              > > We've been using scrum for a while now, and are investigating a few
              > > different toolsets to solve some of the things we wanted addressed.
              One
              > > toolset we've been looking at is the Atlassian toolset (ie. JIRA
              > > w/Greenhopper for story management/etc, Confluence, Crucible, etc)
              and
              > I'm
              > > really liking using Crucible for code inspections. However, it has a
              few
              > > shortcomings that won't be addressed in the short term, so I was
              just
              > > wondering what types of toolsets (or more specifically: what tool
              for
              > code
              > > inspections) other folks were using out there?
              > >
              > > Thanks,
              > > Craig.
              > >
              > > [Non-text portions of this message have been removed]
              > >
              > >
              >
              >


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


              ------------------------------------

              To Post a message, send it to: extremeprogramming@...

              To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...

              ad-free courtesy of objectmentor.comYahoo! Groups Links




              http://www.bbc.co.uk/
              This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
              If you have received it in error, please delete it from your system.
              Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
              Please note that the BBC monitors e-mails sent or received.
              Further communication will signify your consent to this.
            • Craig A
              Appreciate the info - I m aware of coding dojo s but I don t think it would work for our purposes here - we have a large team which is a mix of employees and
              Message 6 of 13 , Dec 3, 2008
              • 0 Attachment
                Appreciate the info - I'm aware of coding dojo's but I don't think it would
                work for our purposes here - we have a large team which is a mix of
                employees and external contractors, and all very geographically diverse.
                We could improve things for the employees, but tough to mandate something
                like this on external contractors, where part of the concern is. But a
                valid idea.

                Thanks.

                --
                Craig.

                On Tue, Dec 2, 2008 at 10:06 AM, agileprog <alexlevin@...> wrote:

                > Again, not a tool but human process. How about setting up a coding
                > Dojo in your team/company? This provides the settings for sharing the
                > know-how and discussing code quality in a relaxed (in the sense of:
                > not related to an actual project) environment.
                >
                > http://www.codingdojo.org
                >
                >
                > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
                > "Craig A" <tabmow99@...> wrote:
                > >
                > > lol... Good point - my mistake. Sorry. So *other* than pair
                > > programming, does anyone have any suggestions on what tools they've
                > used?
                > >
                > >
                > > On Mon, Dec 1, 2008 at 11:49 PM, Adam Sroka <adam.sroka@...> wrote:
                > >
                > > > Uh... you CC'd the XP list. So, Pair Programming.
                > > >
                > > >
                > > > On Mon, Dec 1, 2008 at 7:40 PM, Craig A
                > <tabmow99@...<tabmow99%40gmail.com>>
                > > > wrote:
                > > > > Hi all,
                > > > > We've been using scrum for a while now, and are investigating a few
                > > > > different toolsets to solve some of the things we wanted
                > addressed. One
                > > > > toolset we've been looking at is the Atlassian toolset (ie. JIRA
                > > > > w/Greenhopper for story management/etc, Confluence, Crucible,
                > etc) and
                > > > I'm
                > > > > really liking using Crucible for code inspections. However, it
                > has a few
                > > > > shortcomings that won't be addressed in the short term, so I was
                > just
                > > > > wondering what types of toolsets (or more specifically: what
                > tool for
                > > > code
                > > > > inspections) other folks were using out there?
                > > > >
                > > > > Thanks,
                > > > > Craig.
                > > > >
                > > > > [Non-text portions of this message have been removed]
                > > > >
                > > > >
                > > >
                > > >
                > >
                > >
                > > [Non-text portions of this message have been removed]
                > >
                >
                >
                >


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