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

Re: [scrumdevelopment] Refactoring Justification Language

Expand Messages
  • Ron Jeffries
    Hello, Michael. On Wednesday, June 30, 2010, at 5:47:49 PM, you ... http://xprogramming.com/blog/why-is-refactoring-a-must/ Ron Jeffries www.XProgramming.com
    Message 1 of 21 , Jun 30, 2010
    • 0 Attachment
      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
      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
      Message 2 of 21 , Jun 30, 2010
      • 0 Attachment
        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@...> 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
        ... s/you re/your/ That sentence went through an unfortunate attempt at refactoring that broke one of the tests :-D
        Message 3 of 21 , Jun 30, 2010
        • 0 Attachment
          On Wed, Jun 30, 2010 at 3:54 PM, Adam Sroka <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...)
          >

          s/you're/your/

          That sentence went through an unfortunate attempt at "refactoring"
          that broke one of the tests :-D

          > On Wed, Jun 30, 2010 at 3: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)
          >>
          >>
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.