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

Re: [scrumdevelopment] Refactoring Justification Language

Expand Messages
  • Michael James
    The case for refactoring doesn t depend entirely on the inevitability of changing requirements. Even with static requirements, my first coding/design attempts
    Message 1 of 21 , Jun 30, 2010
    • 0 Attachment
      The case for refactoring doesn't depend entirely on the inevitability of changing requirements.  Even with static requirements, my first coding/design attempts will be suboptimal.  I could stare into space and try to come up with the perfect code in my head, then type in perfectly at the keypunch machine.  But I'll learn more by trying some design, then partially melting it down and reconstituting it after some reflection.

      It's an academic point, since a static understanding of the requirements doesn't exist, but might be useful when a client doesn't realize that yet.

      Looking at the question behind the original question, probably a lot of other stuff could stand improvement if the team doesn't see the point of refactoring.  The times I've been sent out to address specific "engineering problems" I've discovered pretty severe management or teamwork issues.

      --mj

      On Jun 30, 2010, at 3:54 PM, Adam Sroka wrote:

       

      That's a great article. The main thing it adds, that neither Michael nor I said, is that changing requirements are a fundamental assumption of Scrum (and other Agile processes). So, you can't actually be doing Scrum and not have to deal with the problem of a changing system that requires constant design improvement.

      ...Well, you can, but you're system will eventually grow so complex that Scrum will cease to work for you (And then you will decide to rewrite it...)

      On Wed, Jun 30, 2010 at 3:38 PM, Ron Jeffries <ronjeffries@ acm.org> wrote:
       

      Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you
      wrote:



      > Can someone give me a two or three sentence explanation of why refactoring
      > is an essential part of agility and emergent design, why it is important and
      > essential, and how much time should be set aside for the activity? It has to
      > be simple and clear enough for non-techies to understand. I¹m documenting
      > what I think to be things we can do to improve our development process. One
      > of the problems is that we are not refactoring.

      http://xprogramming .com/blog/ why-is-refactori ng-a-must/

      Ron Jeffries
      www.XProgramming. com
      www.xprogramming. com/blog
      Thousands of years ago, the first man discovered how to make fire.
      He was probably burned at the stake he had taught his brothers to
      light - Howard Roark (The Fountainhead, Ayn Rand)




    • Ron Jeffries
      Hello, Michael. On Wednesday, June 30, 2010, at 7:14:54 PM, you ... Exactly ... ... I don t think it is academic at all. Even when requirements don t change
      Message 2 of 21 , Jun 30, 2010
      • 0 Attachment
        Hello, Michael. On Wednesday, June 30, 2010, at 7:14:54 PM, you
        wrote:

        > The case for refactoring doesn't depend entirely on the
        > inevitability of changing requirements. Even with static
        > requirements, my first coding/design attempts will be suboptimal.
        > I could stare into space and try to come up with the perfect code
        > in my head, then type in perfectly at the keypunch machine. But
        > I'll learn more by trying some design, then partially melting it
        > down and reconstituting it after some reflection.

        Exactly ...

        > It's an academic point, since a static understanding of the
        > requirements doesn't exist, but might be useful when a client doesn't realize that yet.

        I don't think it is academic at all. Even when requirements don't
        change much, refactoring is just as important. The code //must//
        evolve. All the design //cannot// be done at the beginning, or it
        ain't Agile.

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
      • Michael James
        Wait a minute. ... --mj (who should be writing something else right now)
        Message 3 of 21 , Jun 30, 2010
        • 0 Attachment
          Wait a minute.

          On Jun 30, 2010, Ron Jeffries wrote:
          > or it ain't Agile.

          On Feb 10, 2009, Ron Jeffries wrote:
          > Personally, I think the question “Is X Agile,” is a waste of time. Teams don’t get paid for being Agile, they get paid for producing good software in short amounts of time.

          Sometime in the 19th Century, Emerson wrote:
          > A foolish consistency is hobgoblin of little minds.

          --mj (who should be writing something else right now)
        • Adam Sroka
          ... I don t disagree, but I think it is mostly semantics. I wasn t drawing a distinction between requirements that change and our changing understanding of
          Message 4 of 21 , Jun 30, 2010
          • 0 Attachment
            On Wed, Jun 30, 2010 at 4:27 PM, Ron Jeffries <ronjeffries@...> wrote:
            > Hello, Michael.  On Wednesday, June 30, 2010, at 7:14:54 PM, you
            > wrote:
            >
            >> The case for refactoring doesn't depend entirely on the
            >> inevitability of changing requirements.  Even with static
            >> requirements, my first coding/design attempts will be suboptimal.
            >> I could stare into space and try to come up with the perfect code
            >> in my head, then type in perfectly at the keypunch machine.  But
            >> I'll learn more by trying some design, then partially melting it
            >> down and reconstituting it after some reflection.
            >
            > Exactly ...
            >
            >> It's an academic point, since a static understanding of the
            >> requirements doesn't exist, but might be useful when a client doesn't realize that yet.
            >
            > I don't think it is academic at all. Even when requirements don't
            > change much, refactoring is just as important. The code //must//
            > evolve. All the design //cannot// be done at the beginning, or it
            > ain't Agile.
            >

            I don't disagree, but I think it is mostly semantics. I wasn't drawing
            a distinction between requirements that change and our changing
            understanding of requirements that haven't really changed themselves.
            I am not convinced that this is a useful distinction to draw.

            When we use an Agile approach we assume that things change. We assume
            this both because we accept that it is inevitable and because even if
            it weren't inevitable it would still be useful.
          • Ron Jeffries
            Hello, Adam. On Wednesday, June 30, 2010, at 7:41:06 PM, you ... Well, refactoring isn t about requirements, though, is it? It s about design. And our
            Message 5 of 21 , Jun 30, 2010
            • 0 Attachment
              Hello, Adam. On Wednesday, June 30, 2010, at 7:41:06 PM, you
              wrote:

              >> I don't think it is academic at all. Even when requirements don't
              >> change much, refactoring is just as important. The code //must//
              >> evolve. All the design //cannot// be done at the beginning, or it
              >> ain't Agile.

              > I don't disagree, but I think it is mostly semantics. I wasn't drawing
              > a distinction between requirements that change and our changing
              > understanding of requirements that haven't really changed themselves.
              > I am not convinced that this is a useful distinction to draw.

              > When we use an Agile approach we assume that things change. We assume
              > this both because we accept that it is inevitable and because even if
              > it weren't inevitable it would still be useful.

              Well, refactoring isn't about requirements, though, is it? It's
              about design. And our knowledge of the design arrives incrementally
              no matter what.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              You can observe a lot by watching. --Yogi Berra
            • Adam Sroka
              ... Yep. I can see how changing requirements has a certain amount of cognitive dissonance. There are two closely related ideas here: what the customer wants
              Message 6 of 21 , Jun 30, 2010
              • 0 Attachment
                On Wed, Jun 30, 2010 at 4:50 PM, Ron Jeffries <ronjeffries@...> wrote:
                >
                >
                >
                > Hello, Adam. On Wednesday, June 30, 2010, at 7:41:06 PM, you
                > wrote:
                >
                > >> I don't think it is academic at all. Even when requirements don't
                > >> change much, refactoring is just as important. The code //must//
                > >> evolve. All the design //cannot// be done at the beginning, or it
                > >> ain't Agile.
                >
                > > I don't disagree, but I think it is mostly semantics. I wasn't drawing
                > > a distinction between requirements that change and our changing
                > > understanding of requirements that haven't really changed themselves.
                > > I am not convinced that this is a useful distinction to draw.
                >
                > > When we use an Agile approach we assume that things change. We assume
                > > this both because we accept that it is inevitable and because even if
                > > it weren't inevitable it would still be useful.
                >
                > Well, refactoring isn't about requirements, though, is it? It's
                > about design. And our knowledge of the design arrives incrementally
                > no matter what.
                >

                Yep. I can see how "changing requirements" has a certain amount of
                cognitive dissonance. There are two closely related ideas here: what
                the customer wants it to do, and how the developer makes it do that.
                If you are following an Agile approach both of those things arrive
                incrementally. The advantage to ignoring the bits that haven't arrived
                yet is that it keeps the design simple for now. Refactoring is
                necessary to keep the design simple as we go.
              • Michael Wollin
                Ron, I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring,
                Message 7 of 21 , Jun 30, 2010
                • 0 Attachment
                  Re: [scrumdevelopment] Refactoring Justification Language Ron,

                  I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring, emergent design and TDD as well. But I am having trouble distilling the case down to extreme brevity so that even the busy executives can get the heart of it with a quick glance. I’ll come up with something.

                  I have 14 or so “suggestions” that I plan to champion. This is just one.  

                  By the way, someone once wrote in a book that you can tell if an agile (or scrum) team is working well if they are having fun, or some such. I wish I could find that one-liner to use as a quote. Might have been yours.

                  Michael



                  On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@...> wrote:


                   
                   
                     

                  Hello, Michael.  On Wednesday, June 30, 2010, at 5:47:49 PM, you
                  wrote:

                  > Can someone give me a two or three sentence explanation of why refactoring
                  > is an essential part of agility and emergent design, why it is important and
                  > essential, and how much time should be set aside for the activity? It has to
                  > be simple and clear enough for non-techies to understand. I’m documenting
                  > what I think to be things we can do to improve our development process. One
                  > of the problems is that we are not refactoring.

                  http://xprogramming.com/blog/why-is-refactoring-a-must/

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  Thousands of years ago, the first man discovered how to make fire.
                  He was probably burned at the stake he had taught his brothers to
                  light - Howard Roark (The Fountainhead, Ayn Rand)

                   
                     


                • Adam Sroka
                  You re first mistake is trying to talk to executives about refactoring at all. They don t need to know about that any more than I need to know the details of
                  Message 8 of 21 , Jun 30, 2010
                  • 0 Attachment
                    You're first mistake is trying to talk to executives about refactoring at all. They don't need to know about that any more than I need to know the details of their jobs. The fact that they want to know and/or that you feel the need to tell them is itself a huge sign of dysfunction (no offense intended.)

                    On Wed, Jun 30, 2010 at 7:58 PM, Michael Wollin <yahoo@...> wrote:
                     

                    Ron,

                    I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring, emergent design and TDD as well. But I am having trouble distilling the case down to extreme brevity so that even the busy executives can get the heart of it with a quick glance. I’ll come up with something.

                    I have 14 or so “suggestions” that I plan to champion. This is just one.  

                    By the way, someone once wrote in a book that you can tell if an agile (or scrum) team is working well if they are having fun, or some such. I wish I could find that one-liner to use as a quote. Might have been yours.

                    Michael





                    On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@...> wrote:


                     
                     
                       

                    Hello, Michael.  On Wednesday, June 30, 2010, at 5:47:49 PM, you
                    wrote:

                    > Can someone give me a two or three sentence explanation of why refactoring
                    > is an essential part of agility and emergent design, why it is important and
                    > essential, and how much time should be set aside for the activity? It has to
                    > be simple and clear enough for non-techies to understand. I’m documenting
                    > what I think to be things we can do to improve our development process. One
                    > of the problems is that we are not refactoring.

                    http://xprogramming.com/blog/why-is-refactoring-a-must/

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    Thousands of years ago, the first man discovered how to make fire.
                    He was probably burned at the stake he had taught his brothers to
                    light - Howard Roark (The Fountainhead, Ayn Rand)

                     
                       



                  • Mark Levison
                    ... Well if you can t find the original source you can credit me :-) I ve said often enough too. Somethings just don t need a source. Cheers Mark *Mark
                    Message 9 of 21 , Jun 30, 2010
                    • 0 Attachment
                      On Wed, Jun 30, 2010 at 10:58 PM, Michael Wollin <yahoo@...> wrote:


                      By the way, someone once wrote in a book that you can tell if an agile (or scrum) team is working well if they are having fun, or some such. I wish I could find that one-liner to use as a quote. Might have been yours.

                      Well if you can't find the original source you can credit me :-) I've said often enough too. Somethings just don't need a source.

                      Cheers
                      Mark
                      Blog | Twitter | Office: (613) 862-2538
                    • woynam
                      Take a look at the auto industry. The vast majority of companies update their models annually, with major makeovers occurring every few years. Each refresh
                      Message 10 of 21 , Jul 1, 2010
                      • 0 Attachment
                        Take a look at the auto industry. The vast majority of companies update their models annually, with major makeovers occurring every few years.

                        Each refresh typically contains hundreds of small engineering changes, many of which address technical issues, and not end-user "requirements". For example, a component may be redesigned so that it has a longer time to failure.

                        Until we invent perfect engineers, or infinite budgets, we'll always be faced with the problem of coming up with a workable solution in a short amount of time. In simple terms, that's engineering. Only after we've used the product for some period of time can we accurately gauge the "goodness" of the design, and correct it as necessary.

                        Refactoring is simply accepting that our software may meet our functional needs, but not our technical needs. Over time, the technical debt will affect our ability to meet the functional needs.

                        Mark

                        --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
                        >
                        > Ron,
                        >
                        > I was going to use that article of yours as a reference link, along with one
                        > by Martin Fowler. Neil Ford has a beautiful presentation about refactoring,
                        > emergent design and TDD as well. But I am having trouble distilling the case
                        > down to extreme brevity so that even the busy executives can get the heart
                        > of it with a quick glance. I¹ll come up with something.
                        >
                        > I have 14 or so ³suggestions² that I plan to champion. This is just one.
                        >
                        > By the way, someone once wrote in a book that you can tell if an agile (or
                        > scrum) team is working well if they are having fun, or some such. I wish I
                        > could find that one-liner to use as a quote. Might have been yours.
                        >
                        > Michael
                        >
                        >
                        >
                        > On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@...> wrote:
                        >
                        > >
                        > >
                        > >
                        > >
                        > >
                        > > Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you
                        > > wrote:
                        > >
                        > >> > Can someone give me a two or three sentence explanation of why refactoring
                        > >> > is an essential part of agility and emergent design, why it is important >>
                        > and
                        > >> > essential, and how much time should be set aside for the activity? It has
                        > >> to
                        > >> > be simple and clear enough for non-techies to understand. I¹m documenting
                        > >> > what I think to be things we can do to improve our development process. One
                        > >> > of the problems is that we are not refactoring.
                        > >
                        > > http://xprogramming.com/blog/why-is-refactoring-a-must/
                        > >
                        > > Ron Jeffries
                        > > www.XProgramming.com
                        > > www.xprogramming.com/blog
                        > > Thousands of years ago, the first man discovered how to make fire.
                        > > He was probably burned at the stake he had taught his brothers to
                        > > light - Howard Roark (The Fountainhead, Ayn Rand)
                        > >
                        > >
                        > >
                        > >
                        > >
                        >
                      • woynam
                        Amen. The time required to refactor the code should be included in the estimate for the story. Executives asking for details below the story level are simply
                        Message 11 of 21 , Jul 1, 2010
                        • 0 Attachment
                          Amen.

                          The time required to refactor the code should be included in the estimate for the story. Executives asking for details below the story level are simply micro-managing.

                          We know from experience that refactoring improves the design of the system, allowing us to evolve the system indefinitely. Without it, the system will eventually rot.

                          So, in a nutshell, by spending time refactoring now, we're actually saving more time in the future. If an executive was to tell you not to refactor, wouldn't he/she actually be telling you to choose the more expensive option?

                          Mark

                          --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                          >
                          > You're first mistake is trying to talk to executives about refactoring at
                          > all. They don't need to know about that any more than I need to know the
                          > details of their jobs. The fact that they want to know and/or that you feel
                          > the need to tell them is itself a huge sign of dysfunction (no offense
                          > intended.)
                          >
                          > On Wed, Jun 30, 2010 at 7:58 PM, Michael Wollin <yahoo@...> wrote:
                          >
                          > >
                          > >
                          > > Ron,
                          > >
                          > > I was going to use that article of yours as a reference link, along with
                          > > one by Martin Fowler. Neil Ford has a beautiful presentation about
                          > > refactoring, emergent design and TDD as well. But I am having trouble
                          > > distilling the case down to extreme brevity so that even the busy executives
                          > > can get the heart of it with a quick glance. I'll come up with something.
                          > >
                          > > I have 14 or so "suggestions" that I plan to champion. This is just one.
                          > >
                          > > By the way, someone once wrote in a book that you can tell if an agile (or
                          > > scrum) team is working well if they are having fun, or some such. I wish I
                          > > could find that one-liner to use as a quote. Might have been yours.
                          > >
                          > > Michael
                          > >
                          > >
                          > >
                          > >
                          > > On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@...> wrote:
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > > Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you
                          > > wrote:
                          > >
                          > > > Can someone give me a two or three sentence explanation of why
                          > > refactoring
                          > > > is an essential part of agility and emergent design, why it is important
                          > > and
                          > > > essential, and how much time should be set aside for the activity? It has
                          > > to
                          > > > be simple and clear enough for non-techies to understand. I'm documenting
                          > > > what I think to be things we can do to improve our development process.
                          > > One
                          > > > of the problems is that we are not refactoring.
                          > >
                          > > http://xprogramming.com/blog/why-is-refactoring-a-must/
                          > >
                          > > Ron Jeffries
                          > > www.XProgramming.com
                          > > www.xprogramming.com/blog
                          > > Thousands of years ago, the first man discovered how to make fire.
                          > > He was probably burned at the stake he had taught his brothers to
                          > > light - Howard Roark (The Fountainhead, Ayn Rand)
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          > >
                          >
                        • Steve Ropa
                          +1 Just as the execs really don t care if you use a for-loop. There really is not reason to ask for permission to do refactoring, its just part of how we
                          Message 12 of 21 , Jul 1, 2010
                          • 0 Attachment
                            +1
                             
                            Just as the execs really don't care if you use a for-loop.  There really is not reason to ask for permission to do refactoring, its just part of how we write code.  Where this tends to pop up is when you find that you are doing rework, or major top down redesign, and calling it refactoring.  Now you are talking about (possibly) seriously impacting the flow of delivering features, and that will definitely get the execs' attention.
                             
                            Steve

                            Sent: Wednesday, June 30, 2010 9:02 PM
                            Subject: Re: [scrumdevelopment] Refactoring Justification Language

                             

                            You're first mistake is trying to talk to executives about refactoring at all. They don't need to know about that any more than I need to know the details of their jobs. The fact that they want to know and/or that you feel the need to tell them is itself a huge sign of dysfunction (no offense intended.)

                            On Wed, Jun 30, 2010 at 7:58 PM, Michael Wollin <yahoo@mercurysw. com> wrote:
                             

                            Ron,

                            I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring, emergent design and TDD as well. But I am having trouble distilling the case down to extreme brevity so that even the busy executives can get the heart of it with a quick glance. I’ll come up with something.

                            I have 14 or so “suggestions” that I plan to champion. This is just one.  

                            By the way, someone once wrote in a book that you can tell if an agile (or scrum) team is working well if they are having fun, or some such. I wish I could find that one-liner to use as a quote. Might have been yours.

                            Michael





                            On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@ acm.org> wrote:


                             
                             
                               

                            Hello, Michael.  On Wednesday, June 30, 2010, at 5:47:49 PM, you
                            wrote:

                            > Can someone give me a two or three sentence explanation of why refactoring
                            > is an essential part of agility and emergent design, why it is important and
                            > essential, and how much time should be set aside for the activity? It has to
                            > be simple and clear enough for non-techies to understand. I’m documenting
                            > what I think to be things we can do to improve our development process. One
                            > of the problems is that we are not refactoring.

                            http://xprogramming .com/blog/ why-is-refactori ng-a-must/

                            Ron Jeffries
                            www.XProgramming. com
                            www.xprogramming. com/blog
                            Thousands of years ago, the first man discovered how to make fire.
                            He was probably burned at the stake he had taught his brothers to
                            light - Howard Roark (The Fountainhead, Ayn Rand)

                             
                               



                          • Wouter Lagerweij
                            I rather like that, since I ve seen that argument (a major chunk or re-work/re-design being called refactoring ). Often there really is a need for re-work
                            Message 13 of 21 , Jul 2, 2010
                            • 0 Attachment
                              I rather like that, since I've seen that argument (a major chunk or re-work/re-design being called 'refactoring'). Often there really is a need for re-work *because* there hasn't been any continuous refactoring going on.
                              You can reverse that argument, of course, if you're getting some resistence in applying good coding practices: we're in a bit of trouble, even requiring some re-work taking X amount of time, and to prevent that in the future the team is going to make sure that they'll be continuously refactoring the code they're working on. 

                              Another nice analogy (I think from Kent Beck's TTD book) was that refactoring is like housekeeping: If you clean up regularly, everything is fine and the effort is minor and predictable. If you let things get really messy, you'll need a large amount of time to clean it up again. And in the mean time, you won't want to have people (customers?) over:-)

                              My addition: If you let things get too messy, they'll rret, and you could get very ill... Such as getting de-motivated or leaving developers, and other ways to cripple yourself.

                              Wouter

                              On Thu, Jul 1, 2010 at 6:51 PM, Steve Ropa <theropas@...> wrote:
                               

                              +1
                               
                              Just as the execs really don't care if you use a for-loop.  There really is not reason to ask for permission to do refactoring, its just part of how we write code.  Where this tends to pop up is when you find that you are doing rework, or major top down redesign, and calling it refactoring.  Now you are talking about (possibly) seriously impacting the flow of delivering features, and that will definitely get the execs' attention.
                               
                              Steve

                              Sent: Wednesday, June 30, 2010 9:02 PM
                              Subject: Re: [scrumdevelopment] Refactoring Justification Language

                               

                              You're first mistake is trying to talk to executives about refactoring at all. They don't need to know about that any more than I need to know the details of their jobs. The fact that they want to know and/or that you feel the need to tell them is itself a huge sign of dysfunction (no offense intended.)

                              On Wed, Jun 30, 2010 at 7:58 PM, Michael Wollin <yahoo@...> wrote:
                               

                              Ron,

                              I was going to use that article of yours as a reference link, along with one by Martin Fowler. Neil Ford has a beautiful presentation about refactoring, emergent design and TDD as well. But I am having trouble distilling the case down to extreme brevity so that even the busy executives can get the heart of it with a quick glance. I’ll come up with something.

                              I have 14 or so “suggestions” that I plan to champion. This is just one.  

                              By the way, someone once wrote in a book that you can tell if an agile (or scrum) team is working well if they are having fun, or some such. I wish I could find that one-liner to use as a quote. Might have been yours.

                              Michael





                              On 6/30/10 6:38 PM, "Ron Jeffries" <ronjeffries@...> wrote:


                               
                               
                                 

                              Hello, Michael.  On Wednesday, June 30, 2010, at 5:47:49 PM, you
                              wrote:

                              > Can someone give me a two or three sentence explanation of why refactoring
                              > is an essential part of agility and emergent design, why it is important and
                              > essential, and how much time should be set aside for the activity? It has to
                              > be simple and clear enough for non-techies to understand. I’m documenting
                              > what I think to be things we can do to improve our development process. One
                              > of the problems is that we are not refactoring.

                              http://xprogramming.com/blog/why-is-refactoring-a-must/

                              Ron Jeffries
                              www.XProgramming.com
                              www.xprogramming.com/blog
                              Thousands of years ago, the first man discovered how to make fire.
                              He was probably burned at the stake he had taught his brothers to
                              light - Howard Roark (The Fountainhead, Ayn Rand)

                               
                                 




                            • Andy Naessens
                              Listen and stop the BS. These lenghty dissertations trying to prove you know. Agile only make you look stupid. Take our local motor mouth. He knows nothing
                              Message 14 of 21 , Jul 2, 2010
                              • 0 Attachment
                                Listen and stop the BS. These lenghty dissertations trying to prove you know. Agile only make you look stupid. Take our local motor mouth. He knows nothing about realistic use of Agile. I myself call him a Scrub bag. Bottom line. Shut up and DO ! Andy Naessens. CTO, Dam
                                Sent from Andy Naessens BlackBerry
                              Your message has been successfully submitted and would be delivered to recipients shortly.