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

Re: Tracking systems (was: Good non-threatening "lunch and learn" video on agility for DBAs?)

Expand Messages
  • bobcorrick@btopenworld.com
    This seemed like an interesting and reasonable request, and I m wondering if Cameron has anything to add, or any offline conversations to report? Currently I m
    Message 1 of 28 , Sep 1, 2009
      This seemed like an interesting and reasonable request, and I'm wondering if Cameron has anything to add, or any offline conversations to report?

      Currently I'm in an environment where there are several tracking systems in use, so an alternative to this concept would be very useful...

      regards
      Bob

      --- In agileDatabases@yahoogroups.com, Cameron Laird <claird@...> wrote:
      >
      > On Wed, Aug 26, 2009 at 09:08:34PM +0900, Curt Sampson wrote:
      > .
      > .
      > .
      > > As a personal example, I've not used a bug tracking system in years,
      > > and I will always recommend fixing whatever it is that's driving you
      > > to want to use a bug tracking system before you go and implement one.
      > .
      > .
      > .
      > !?
      >
      > I must be utterly missing the point. I, personally, don't believe
      > in "bugs", but I'm doing more "issue tracking" this year than ever
      > before. It's a vital part of leadership for me. Please help me
      > understand: how do I fix an environment where tasks sometimes take
      > longer to resolve than generate or define?
      >
    • Curt Sampson
      ... I m sorry that this sounds a bit harsh, but do you really think that leadership is about making long lists of things that are broken? But to more directly
      Message 2 of 28 , Sep 2, 2009
        On 2009-08-28 13:14 +0000 (Fri), Cameron Laird wrote:

        > On Wed, Aug 26, 2009 at 09:08:34PM +0900, Curt Sampson wrote:
        >
        > > As a personal example, I've not used a bug tracking system in years,
        > > and I will always recommend fixing whatever it is that's driving you
        > > to want to use a bug tracking system before you go and implement one.
        >
        > I, personally, don't believe in "bugs", but I'm doing more "issue
        > tracking" this year than ever before. It's a vital part of leadership
        > for me. Please help me understand: how do I fix an environment where
        > tasks sometimes take longer to resolve than generate or define?

        I'm sorry that this sounds a bit harsh, but do you really think that
        leadership is about making long lists of things that are broken?

        But to more directly answer your question: the problem is not that tasks
        sometimes take longer to resolve than generate or define. That's the
        case for me, too. The problem is that you can't fix the things as fast
        as they come in, so you have to queue them up and delay the fixes. This
        probably means that it's not "sometimes" but "most of the time" you
        don't have time to fix the software that you wrote before more problems
        are made apparent.

        There's no easy solution to this. You need to make the choice about
        whether you (and more importantly, your customers) want software that's
        more or less "bug free," or prefer to prioritise other things instead.
        If they want fewer bugs over more features, then you need to focus on
        getting the quality of your code base up to the point where most bugs
        are new, so there's little code to look at when you want to find out
        where the bug was introduced.

        I could give more advice, but this is all pretty well covered in the
        agile texts.

        cjs
        --
        Curt Sampson <cjs@...> +81 90 7737 2974
        Functional programming in all senses of the word:
        http://www.starling-software.com
      • bobcorrick@btopenworld.com
        Curt, I wonder if you would be able to share any details about how you know the state of things - let s say, the state of your software products. I can imagine
        Message 3 of 28 , Sep 3, 2009
          Curt,

          I wonder if you would be able to share any details about how you know the state of things - let's say, the state of your software products.

          I can imagine alternatives to tracking systems and lists, such as:

          * feedback from your customers and users, and your memory

          * a regression test suite that can be executed on a deployed product, to reveal capability and problems

          * version control logs, so you know what has been done (but not what has not been done)

          But I think I am missing the point by focusing on tools and techniques. Any thoughts that you feel able to share about your own system, or recommended reading, may help me to think about my context.

          regards
          Bob


          --- In agileDatabases@yahoogroups.com, Curt Sampson <cjs@...> wrote:
          >
          > On 2009-08-28 13:14 +0000 (Fri), Cameron Laird wrote:
          >
          > > On Wed, Aug 26, 2009 at 09:08:34PM +0900, Curt Sampson wrote:
          > >
          > > > As a personal example, I've not used a bug tracking system in years,
          > > > and I will always recommend fixing whatever it is that's driving you
          > > > to want to use a bug tracking system before you go and implement one.
          > >
          > > I, personally, don't believe in "bugs", but I'm doing more "issue
          > > tracking" this year than ever before. It's a vital part of leadership
          > > for me. Please help me understand: how do I fix an environment where
          > > tasks sometimes take longer to resolve than generate or define?
          >
          > I'm sorry that this sounds a bit harsh, but do you really think that
          > leadership is about making long lists of things that are broken?
          >
          > But to more directly answer your question: the problem is not that tasks
          > sometimes take longer to resolve than generate or define. That's the
          > case for me, too. The problem is that you can't fix the things as fast
          > as they come in, so you have to queue them up and delay the fixes. This
          > probably means that it's not "sometimes" but "most of the time" you
          > don't have time to fix the software that you wrote before more problems
          > are made apparent.
          >
          > There's no easy solution to this. You need to make the choice about
          > whether you (and more importantly, your customers) want software that's
          > more or less "bug free," or prefer to prioritise other things instead.
          > If they want fewer bugs over more features, then you need to focus on
          > getting the quality of your code base up to the point where most bugs
          > are new, so there's little code to look at when you want to find out
          > where the bug was introduced.
          >
          > I could give more advice, but this is all pretty well covered in the
          > agile texts.
          >
          > cjs
          > --
          > Curt Sampson <cjs@...> +81 90 7737 2974
          > Functional programming in all senses of the word:
          > http://www.starling-software.com
          >
        • Curt Sampson
          ... Sure. ... Feedback from your customers is not part of the tracking system: it s the raw material that goes into the tracking system. Memory, is of course
          Message 4 of 28 , Sep 8, 2009
            On 2009-09-03 15:06 -0000 (Thu), bobcorrick@... wrote:

            > I wonder if you would be able to share any details about how you know
            > the state of things - let's say, the state of your software products.

            Sure.

            > I can imagine alternatives to tracking systems and lists, such as:
            > * feedback from your customers and users, and your memory

            Feedback from your customers is not part of the tracking system: it's
            the raw material that goes into the tracking system.

            Memory, is of course one tracking system for currently open bugs. We
            use that, and get assistance from whiteboards, as well. It's certainly
            true that fails pretty rapidly if you have a lot of bugs open for long
            periods of time, but the upside of it is that it's very cheap to run
            compared to a more formal system.

            > * a regression test suite that can be executed on a deployed
            > product, to reveal capability and problems

            The test suite itself is not a tracking system for open bugs; it's only
            the failing tests within it that serve that purpose. We use this on
            occasion, but while it can be a good way of storing the information
            needed to identify a bug, but it can be a less good way to keep a list
            of open bugs, since because the tests aren't normally run, you have to
            remember to go back into your tests and look for ones marked failing.
            (You could just leave the tests running and failing, but that has the
            very, very bad effect of obscuring the moment at which a prevoiusly
            working test fails.)

            > * version control logs, so you know what has been done (but not
            > what has not been done)

            Not really, in terms of tracking open bugs.

            > But I think I am missing the point by focusing on tools and
            > techniques. Any thoughts that you feel able to share about your own
            > system, or recommended reading, may help me to think about my context.

            My strategy, on my products, is triage bugs quickly and, if possible,
            close them quickly. (If it's something I'm not going to be addressing
            any time soon, I just drop a comment in the source so that it can be
            picked up next time that chunk of code gets rewritten.)

            The various agile books out there offer hints as to how to run a
            software project so you can do this. If you can do this, great; you get
            to use the cheap bug tracking I've described above. If you can't, either
            because you don't know how to run a software project like this, or it's
            just one of the many projects out there that is not suited to this way
            of working, you'll have to spend the time and money to put in a more
            expensive system. But do keep in mind, that sucking away part of your
            software development budget to track bugs rather than fix them is not
            the best that can be done.

            cjs
            --
            Curt Sampson <cjs@...> +81 90 7737 2974
            Functional programming in all senses of the word:
            http://www.starling-software.com
          • Joseph Fall
            ... I ve been watching this thread with great interest, because like others, I was interested in alternate approaches to issue tracking. ... 1) Not everybody
            Message 5 of 28 , Sep 8, 2009
              On 8-Sep-09, at 2:14 AM, Curt Sampson wrote:
              > My strategy, on my products, is triage bugs quickly and, if possible,
              > close them quickly. (If it's something I'm not going to be addressing
              > any time soon, I just drop a comment in the source so that it can be
              > picked up next time that chunk of code gets rewritten.)
              >
              I've been watching this thread with great interest, because like
              others, I was interested in alternate approaches to issue tracking.
              However, I don't find this very compelling. Here are my thoughts:
              >


              1) Not everybody on a project team looks at or has access to the
              code. In our case, it is important for non-technical team members to
              be able to report, view, and comment on bugs / issues / enhancements /
              tasks.

              2) While some IDE's provide tools for tracking issues in code (via
              todo comments, etc.), they are not good at prioritizing, and useless
              at tracking discussions about an issue. Also, some issues may not be
              linked to a particular piece of code, so where to put the comment?

              3) While "number of outstanding issues" is a very crude measure of
              progress, it is a measure none the less. In the run up to a release, I
              find it very helpful to be able to monitor its trajectory as a rough
              measure if we our deadlines are realistic (and a measure of how solid
              the code base is for that matter - if 2 issues arise for every one
              fixed, one knows there is likely some serious re-factoring needed).
              Again, this measure could be made from the crude 'issue tracking'
              supplied by an IDE, but only with significant overhead if you want to
              partition issues into different milestones.

              We use Trac - it is open-source, lightweight, integrates with SVN, and
              works very well for us as an integrated project management / issue
              tracking system. I don't feel that the overhead incurred in its
              maintenance is very high - generally an issue gets logged, then marked
              as fixed, really no more work than adding and then deleting a comment
              in the code. For issues that do generate a lot of discussion or re-
              factoring, I'm thankful to have a clean mechanism for recording the
              decisions and progress on the issue.
              I'm not sure I see any advantage to your 'cheap' tracking system, but
              I do think we might loose a fair bit by ditching Trac in its favor.

              just my two bits.
              ...Joseph
              Driftwood Cove Designs

              [Non-text portions of this message have been removed]
            • Cameron Laird
              On Tue, Sep 08, 2009 at 12:55:14PM -0700, Joseph Fall wrote: . . . ... . . . Yeah. My reality is so distant from Mr. Sampson s on this issue that I haven t
              Message 6 of 28 , Sep 8, 2009
                On Tue, Sep 08, 2009 at 12:55:14PM -0700, Joseph Fall wrote:
                .
                .
                .
                > > My strategy, on my products, is triage bugs quickly and, if possible,
                > > close them quickly. (If it's something I'm not going to be addressing
                > > any time soon, I just drop a comment in the source so that it can be
                > > picked up next time that chunk of code gets rewritten.)
                > >
                > I've been watching this thread with great interest, because like
                > others, I was interested in alternate approaches to issue tracking.
                > However, I don't find this very compelling. Here are my thoughts:
                > >
                >
                >
                > 1) Not everybody on a project team looks at or has access to the
                > code. In our case, it is important for non-technical team members to
                > be able to report, view, and comment on bugs / issues / enhancements /
                > tasks.
                >
                > 2) While some IDE's provide tools for tracking issues in code (via
                > todo comments, etc.), they are not good at prioritizing, and useless
                > at tracking discussions about an issue. Also, some issues may not be
                > linked to a particular piece of code, so where to put the comment?
                >
                > 3) While "number of outstanding issues" is a very crude measure of
                > progress, it is a measure none the less. In the run up to a release, I
                > find it very helpful to be able to monitor its trajectory as a rough
                > measure if we our deadlines are realistic (and a measure of how solid
                > the code base is for that matter - if 2 issues arise for every one
                > fixed, one knows there is likely some serious re-factoring needed).
                > Again, this measure could be made from the crude 'issue tracking'
                > supplied by an IDE, but only with significant overhead if you want to
                > partition issues into different milestones.
                >
                > We use Trac - it is open-source, lightweight, integrates with SVN, and
                > works very well for us as an integrated project management / issue
                > tracking system. I don't feel that the overhead incurred in its
                > maintenance is very high - generally an issue gets logged, then marked
                > as fixed, really no more work than adding and then deleting a comment
                > in the code. For issues that do generate a lot of discussion or re-
                > factoring, I'm thankful to have a clean mechanism for recording the
                > decisions and progress on the issue.
                > I'm not sure I see any advantage to your 'cheap' tracking system, but
                > I do think we might loose a fair bit by ditching Trac in its favor.
                .
                .
                .
                Yeah.

                My reality is so distant from Mr. Sampson's on this issue that
                I haven't figured out yet how to respond. Briefly, "bug"-s are
                the least of my problems, source code is a *liability*, and the
                only artifact on which I can get my stakeholders to come close
                to a common reading is a tracked Issue--certainly not source
                code.

                As a coder, I'm all in favor of solving problems quickly, and
                making intelligent use of source-code control, comments, and
                other such techniques; I certainly do these things on my own.
              • Curt Sampson
                ... It s certainly the case, as I even mentioned in my post, that many people here are going to have very, very different approaches from my extremely agile
                Message 7 of 28 , Sep 8, 2009
                  On 2009-09-08 20:22 +0000 (Tue), Cameron Laird wrote:

                  > [Massive include of my entire post removed; Cameron; it would be
                  > polite to respect the time of the many readers of this list by
                  > deleting unnecessary text from your posts.]
                  >
                  > My reality is so distant from Mr. Sampson's on this issue that
                  > I haven't figured out yet how to respond.

                  It's certainly the case, as I even mentioned in my post, that many
                  people here are going to have very, very different approaches from my
                  extremely agile one. There are two reasons for this.

                  The first, as I mentioned, is that projects themselves inherently
                  differ, and have differing requirements. A safety-critical embedded
                  system where field upgrades are unsafe, expensive or impossible (such as
                  aircraft control systems) is quite a different beast from a consumer web
                  site (such as Amazon), and the appropriate amount to spend on, say,
                  testing versus developent will be radically different.

                  The second is that a lot of developers and managers out there simply
                  don't understand agile development, and can't conceive of a world other
                  than their own.

                  It's quite easy, I believe, to tell in which group you fall. If you find
                  yourself saying, "he's lucky to be able to work that way and save so
                  much money and time on process," and you have looked at doing things my
                  way but for specific reasons you've identified you've had to use more
                  heavyweight processes, you're probably someone who "gets" agile. If
                  you simply think I'm a crazy nut and my projects are fairly successful
                  through sheer luck, you probably don't understand agile very well.

                  > Briefly...source code is a *liability*, and the only artifact on which
                  > I can get my stakeholders to come close to a common reading is a
                  > tracked Issue--certainly not source code.

                  Again, it comes down to your understanding of agile here. The source
                  code and the systems you use to build and deploy it are your primary
                  artifact, whether you like it or not. If you've consciously chosen to
                  use an inaccurate proxy when making decisions about your project, you
                  have good reasons for it, and you're working to fix that as best you
                  can, you're agile. If you do it through ignorance of what your primary
                  artifact really is, you're not agile, or at least you're not applying it
                  to that project.

                  > As a coder, I'm all in favor of solving problems quickly, and
                  > making intelligent use of source-code control, comments, and
                  > other such techniques; I certainly do these things on my own.

                  If you haven't already, think about that. On a project on which you
                  work alone as coder, manager, customer, and everything else, do you
                  immediately sit down and spend time setting up Trac and everything
                  else? I'm guessing not. These systems are not inherently good in and of
                  themselves; they're simply one of a variety of tools available to help
                  fix another problem.

                  As an example of other tools available, we can consider a major system
                  that I'm currently working on. It's an automated options trading system
                  that includes not only the trading program itself, but a stock exchange
                  simulator, various logging and reporting tools that themselves comprise
                  a DBMS of sorts, and all sorts of other goodies. By using Haskell, I
                  can write a system in ten or twenty thousand lines of code that would
                  take me one or two hundred thousand lines of code in Java or C++. Simply
                  decreasing the size of the code base by an order of magnitude or so
                  allows an individual developer to have a much better understanding of
                  the entire system, review code more quickly, and so on. That is part of
                  what allows me to avoid building yet more bug tracking and documentation
                  machinery.

                  On 2009-09-08 12:55 -0700 (Tue), Joseph Fall wrote:

                  > However, I don't find [Curt's approach] this very compelling.

                  Non-agile people generally don't. See my comments above.

                  > 1) Not everybody on a project team looks at or has access to the
                  > code. In our case, it is important for non-technical team members to
                  > be able to report, view, and comment on bugs / issues / enhancements /
                  > tasks.

                  It's the same for my projects; I simply deal with it more efficiently.
                  Non-technical people have no problem talking with developers about the
                  current state of the system, and reading the text files or whiteboards
                  that assist in project tracking if we use such things.

                  > 2) While some IDE's provide tools for tracking issues in code (via
                  > todo comments, etc.), they are not good at prioritizing....

                  Nor are bug tracking systems good at prioritizing. As the code changes,
                  bugs change or vanish, and it's all to easy for the bug tracking system
                  to get out of sync with the developers' understanding of the code, much
                  less the reality of the situation. Surely you've had the experience
                  of looking at a year-old issue report and realizing that it has no
                  relevance at all to the system as it stands today.

                  > 3) While "number of outstanding issues" is a very crude measure of
                  > progress, it is a measure none the less.

                  It certainly is, and I use that metric myself. An issue tracking system
                  is only one way of getting this metric, however. To address an example
                  you give:

                  > ...if 2 issues arise for every one fixed, one knows there is likely
                  > some serious re-factoring needed).

                  Sure. But there are more direct and accurate ways of getting this
                  information: ask your developers. When it starts to get difficult to
                  add features and every change seems like a struggle, some sort of
                  refactoring or change in design is needed even if the developers aren't
                  adding new bugs every time they fix an old one. If you've got careful
                  developers working on your code, they may be avoiding adding new bugs
                  with every change not because the system doesn't need refactoring, but
                  simply because they're spending a lot of extra time and effort to make
                  the changes without introducing new bugs.

                  > I don't feel that the overhead incurred in [Trac's] maintenance is
                  > very high - generally an issue gets logged, then marked as fixed,
                  > really no more work than adding and then deleting a comment in the
                  > code.

                  If you really only use it as a to-do list with a one-line summary of
                  every item, why not just use a whiteboard? That would have the advantage
                  that everything would be there, staring you in the face; review is
                  constant and very quick, and issues that need to be triaged get triaged,
                  rather than lingering in the database and cluttering reports. There's
                  no point in tracking things that are not going to be fixed before they
                  disappear on their own.

                  cjs
                  --
                  Curt Sampson <cjs@...> +81 90 7737 2974
                  Functional programming in all senses of the word:
                  http://www.starling-software.com
                • bobcorrick@btopenworld.com
                  Curt, Many thanks for taking the time to respond. I found it helped to put things into perspective for me, about tracking and about alternatives to tracking.
                  Message 8 of 28 , Sep 9, 2009
                    Curt,

                    Many thanks for taking the time to respond. I found it helped to put things into perspective for me, about tracking and about alternatives to tracking.

                    regards,
                    Bob

                    --- In agileDatabases@yahoogroups.com, Curt Sampson <cjs@...> wrote:
                    >
                    > On 2009-09-03 15:06 -0000 (Thu), bobcorrick@... wrote:
                    >
                    > > I wonder if you would be able to share any details about how you know
                    > > the state of things - let's say, the state of your software products.
                    >
                    > Sure.
                    >
                    > > I can imagine alternatives to tracking systems and lists, such as:
                    > > * feedback from your customers and users, and your memory
                    >
                    > Feedback from your customers is not part of the tracking system: it's
                    > the raw material that goes into the tracking system.
                    >
                    > Memory, is of course one tracking system for currently open bugs. We
                    > use that, and get assistance from whiteboards, as well. It's certainly
                    > true that fails pretty rapidly if you have a lot of bugs open for long
                    > periods of time, but the upside of it is that it's very cheap to run
                    > compared to a more formal system.
                    >
                    > > * a regression test suite that can be executed on a deployed
                    > > product, to reveal capability and problems
                    >
                    > The test suite itself is not a tracking system for open bugs; it's only
                    > the failing tests within it that serve that purpose. We use this on
                    > occasion, but while it can be a good way of storing the information
                    > needed to identify a bug, but it can be a less good way to keep a list
                    > of open bugs, since because the tests aren't normally run, you have to
                    > remember to go back into your tests and look for ones marked failing.
                    > (You could just leave the tests running and failing, but that has the
                    > very, very bad effect of obscuring the moment at which a prevoiusly
                    > working test fails.)
                    >
                    > > * version control logs, so you know what has been done (but not
                    > > what has not been done)
                    >
                    > Not really, in terms of tracking open bugs.
                    >
                    > > But I think I am missing the point by focusing on tools and
                    > > techniques. Any thoughts that you feel able to share about your own
                    > > system, or recommended reading, may help me to think about my context.
                    >
                    > My strategy, on my products, is triage bugs quickly and, if possible,
                    > close them quickly. (If it's something I'm not going to be addressing
                    > any time soon, I just drop a comment in the source so that it can be
                    > picked up next time that chunk of code gets rewritten.)
                    >
                    > The various agile books out there offer hints as to how to run a
                    > software project so you can do this. If you can do this, great; you get
                    > to use the cheap bug tracking I've described above. If you can't, either
                    > because you don't know how to run a software project like this, or it's
                    > just one of the many projects out there that is not suited to this way
                    > of working, you'll have to spend the time and money to put in a more
                    > expensive system. But do keep in mind, that sucking away part of your
                    > software development budget to track bugs rather than fix them is not
                    > the best that can be done.
                    >
                    > cjs
                    > --
                    > Curt Sampson <cjs@...> +81 90 7737 2974
                    > Functional programming in all senses of the word:
                    > http://www.starling-software.com
                    >
                  • Cameron Laird
                    On Wed, Sep 09, 2009 at 06:45:44AM +0900, Curt Sampson wrote: . . . ... . . . I entirely agree with Curt s proposal that postings be trimmed and succinct. I
                    Message 9 of 28 , Sep 9, 2009
                      On Wed, Sep 09, 2009 at 06:45:44AM +0900, Curt Sampson wrote:
                      .
                      .
                      .
                      > On 2009-09-08 20:22 +0000 (Tue), Cameron Laird wrote:
                      >
                      > > [Massive include of my entire post removed; Cameron; it would be
                      > > polite to respect the time of the many readers of this list by
                      > > deleting unnecessary text from your posts.]
                      .
                      .
                      .
                      I entirely agree with Curt's proposal that postings be trimmed
                      and succinct. I had, in fact, thought myself an exemplar in that
                      regard.

                      As best I can tell, my follow-up of 8 September 2009 included one
                      paragraph of two sentences from Curt's earlier post; I suspect a
                      bit of confusion about who wrote what has crept into this thread.
                      I write this to the list in order to save the time of others who
                      might benefit from help in puzzling out where we are in the con-
                      versation.
                    • Curt Sampson
                      ... Thanks. That s all I ask. I m well aware that there are many, many reasons in the real world not to do things the way I do. The important thing is not that
                      Message 10 of 28 , Sep 9, 2009
                        On 2009-09-09 09:36 -0000 (Wed), bobcorrick@... wrote:

                        > Many thanks for taking the time to respond. I found it helped to put
                        > things into perspective for me, about tracking and about alternatives
                        > to tracking.

                        Thanks. That's all I ask. I'm well aware that there are many, many
                        reasons in the real world not to do things the way I do.

                        The important thing is not that you do what I do, but that you do the
                        best you can under the circumstances.

                        (Up in Canada, The Canadian Broadcasting Corporation once had a contest
                        to come up with the Canadian equivalant of the phrase "As American as
                        apple pie." The almost unanimous winner was, "As Canadian as possible
                        under the circumstances.")

                        cjs
                        --
                        Curt Sampson <cjs@...> +81 90 7737 2974
                        Functional programming in all senses of the word:
                        http://www.starling-software.com
                      • Joseph Fall
                        ... That s a bit presumptive and dismissive. ... I should have prefaced my statements by saying I work with a remote team - we re spread out over the
                        Message 11 of 28 , Sep 9, 2009
                          > Non-agile people generally don't. See my comments above.
                          That's a bit presumptive and dismissive.
                          >


                          > If you really only use it as a to-do list with a one-line summary of
                          > every item, why not just use a whiteboard?
                          I should have prefaced my statements by saying I work with a remote
                          team - we're spread out over the continent. We don't ever have face-
                          to-face meetings. I realize that hampers or even disables many agile
                          methods (hard to have stand-ups), but we do our best to apply the
                          principles with the tools we've got. In a sense, Trac does serve as
                          our online, asynchronous whiteboard. Asynchronous is important for
                          us (different time zones, even different counties with different
                          holidays), but I realize much of being agile is about being
                          synchronized.

                          We could (and have tried to) use a more 'agile' tool (like a
                          writeboard in Backpack say), but I really think we do derive benefits
                          from Trac, as I laid out in my last post. In particular, although Trac
                          does often serve simply as a glorified to-do list, it provides
                          mechanisms for setting goals (milestones), prioritizing, moving issues
                          between milestones, and tracking short, medium, and long-term issues
                          in a consistent framework. As I said, it also provides a mechanism
                          for recording discussions and decisions about issues that required
                          more deliberations and longer time-frames to resolve. Having all
                          these tools integrated has improved the quality, and I'd say the
                          efficiency of our process.

                          Thanks for your thoughtful response - I think I understand your
                          approach better now.

                          ...Joseph
                          Driftwood Cove Designs

                          [Non-text portions of this message have been removed]
                        • Curt Sampson
                          ... I don t think so. I m simply not hearing any understanding of agile amongst these people. It s the critics of agile, who insist that they would never do
                          Message 12 of 28 , Sep 10, 2009
                            On 2009-09-09 09:46 -0700 (Wed), Joseph Fall wrote:

                            > > Non-agile people generally don't. See my comments above.
                            > That's a bit presumptive and dismissive.

                            I don't think so. I'm simply not hearing any understanding of agile
                            amongst these people. It's the critics of agile, who insist that they
                            would never do these things under any circumstances, that are being
                            presumptive and dismissive.

                            > In particular, although Trac does often serve simply as a glorified
                            > to-do list, it provides mechanisms for setting goals (milestones),
                            > prioritizing, moving issues between milestones, and tracking short,
                            > medium, and long-term issues in a consistent framework.

                            It certainly does, and if you're going to have a lot of issues you
                            want to track in detail, it's an excellent tool for that.

                            My point is that that doesn't mean that having to track a lot of issues
                            in detail is a good thing, or that software projects must do that in
                            order to be successful. In fact, it's a distinct sign of lack of success
                            in at least certain areas, in my opinion.

                            To oversimplify: if you have no bugs, you've no need of a bug tracker.

                            cjs
                            --
                            Curt Sampson <cjs@...> +81 90 7737 2974
                            Functional programming in all senses of the word:
                            http://www.starling-software.com
                          Your message has been successfully submitted and would be delivered to recipients shortly.