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

Re: Refactoring Justification Language

Expand Messages
  • 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 1 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 2 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 3 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 4 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.