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

striking the balance

Expand Messages
  • D. AndrĂ© Dhondt
    In response to Ron Jeffrie s request for topics that I d be interested in hearing about in this forum: Striking The Balance How do you know, in the cadence of
    Message 1 of 211 , May 23, 2007
      In response to Ron Jeffrie's request for topics that I'd be interested in
      hearing about in this forum:

      Striking The Balance

      How do you know, in the cadence of red-green-refactor, if it's OK to
      refactor that code that you can now see is rotting, but is technically out
      of the scope of this card (and not something that you wrote today)?

      On my team, we try to 'make it work, make it right, make it fast', but
      sometimes our estimates are wrong and we only have time to 'make it work'.
      Then we're out of time on the card and we move on, 'cause there's an
      iteration to finish. This is probably a mistake--it probably incurs code
      debt. But it's a lot less clear to me when code smell I see today came from
      another day's work. I also think it's a mistake to refactor mercilessly
      down into the bowels of the code to the extent that we blow budget on a
      card. There's a really difficult balance here, especially when our legacy
      code, and even the code we wrote last week or last month or last year begins
      to seem a bit rigid or rotten or otherwise smelly.

      So, what I'm saying is that we use our card estimates (multiplied by some
      velocity factor to identify hours) to figure out if we have time to clean up
      something that we didn't write today but that needs attention. Are there
      other indicators you use?




      --
      D. André Dhondt

      If you're a software developer in the area, join Agile Philly (
      http://groups.yahoo.com/group/agilephilly/)!


      [Non-text portions of this message have been removed]
    • Ron Jeffries
      Hello, Paul. I saved this up for a while primarily because I think it s so good that people deserve more than one chance to see it. ... Ever so true. As he
      Message 211 of 211 , Jun 13, 2007
        Hello, Paul. I saved this up for a while primarily because I think
        it's so good that people deserve more than one chance to see it.

        On Monday, June 4, 2007, at 8:10:59 AM, you wrote:

        > Its very dangerous to skip refactoring in order to meet an iteration
        > end date because the budget for your next iteration will include even
        > less margin for refactoring (because of the higher aparent velocity)
        > and so a downward spiral will ensue. Debt should only be incured if
        > there is a compelling reason to do so - and a looming end of iteration
        > is generally *not* a compelling reason.

        > Of course in reality there are tradoffs such as dealing with ugly
        > legacy code and so judgment calls must be made. All I can say is try
        > to judge the cost of not doing it: is the code at or near the end of
        > its life (in terms of changes) ?, will it be even harder than it is
        > now the next time someone considers the same refactor ?.

        > But before you put off a refactor remember that not doing it costs
        > your business real money every time someone interacts with that code
        > in any way, even if only to read it so its probably fair to say that
        > every 5 mins spent refactoring saves an hour over the life of the project.

        > A few operational tips: Dont leave refactoring to the end of a story,
        > do it incrementally. Use refactoring as a way of comprehending
        > existing code so that you get it effectivly for free.

        Ever so true. As he knows, I was disappointed to see Jim Shore come
        out "in favor" of technical debt in his new book. He is of course
        technically correct that "sometimes" it is justified.

        My guess is that most of the time when **I** think it's justified,
        it isn't. Imagine what I think about when someone else thinks it's
        justified.

        Over the medium and long term, keeping clean is the way to go fast,
        in my experience.

        Ron Jeffries
        www.XProgramming.com
        Those who believe complexity is elegant or required don't understand
        the problem. -- John Streiff
      Your message has been successfully submitted and would be delivered to recipients shortly.