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

Re: [scrumdevelopment] Refactoring Justification Language

Expand Messages
  • Adam Sroka
    Refactoring is essential because requirements inevitably change and therefore code inevitably changes to satisfy them. When code which adheres to principles of
    Message 1 of 21 , Jun 30, 2010
    • 0 Attachment
      Refactoring is essential because requirements inevitably change and therefore code inevitably changes to satisfy them. When code which adheres to principles of good design is changed it may no longer adhere to those principles. Refactoring is a technique that allows us to improve the design of the code once we have changed it.

      On Wed, Jun 30, 2010 at 2:47 PM, Michael Wollin <yahoo@...> 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.


    • Michael James
      We reduce errors and the future cost of change when we do the simplest thing that could possibly work. But our first attempt to solve a problem will be a bit
      Message 2 of 21 , Jun 30, 2010
      • 0 Attachment
        We reduce errors and the future cost of change when we do the simplest thing that could possibly work.  But our first attempt to solve a problem will be a bit messy, as innovation requires mistakes.  So my pair and I should spend a few minutes refactoring after every few minutes writing tests and code.

        --mj

        On Jun 30, 2010, at 2:47 PM, Michael Wollin 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.

      • Adam Sroka
        I agree with everything you say. However, you are describing the advantages of TDD as a whole and not of refactoring by itself. Refactoring is useful by
        Message 3 of 21 , Jun 30, 2010
        • 0 Attachment
          I agree with everything you say. However, you are describing the
          advantages of TDD as a whole and not of refactoring by itself.
          Refactoring is useful by itself, but it is highly synergistic with the
          other practices of TDD (test-first programming and simple design),
          pair programming, and continuous integration.

          On Wed, Jun 30, 2010 at 3:15 PM, Michael James <michael@...> wrote:
          >
          >
          >
          > We reduce errors and the future cost of change when we do the simplest thing that could possibly work.  But our first attempt to solve a problem will be a bit messy, as innovation requires mistakes.  So my pair and I should spend a few minutes refactoring after every few minutes writing tests and code.
          >
          > --mj
          >
          > On Jun 30, 2010, at 2:47 PM, Michael Wollin 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.
          >
          >
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 of 21 , Jul 1 7:06 AM
                                  • 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 17 of 21 , Jul 1 7:11 AM
                                    • 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 18 of 21 , Jul 1 9:51 AM
                                      • 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 19 of 21 , Jul 2 3:16 AM
                                        • 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 20 of 21 , Jul 2 5:09 AM
                                          • 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.