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

Re: [scrumdevelopment] Re: Technical Debt and the Product Backlog

Expand Messages
  • Ron Jeffries
    ... Excellent. But seriously, I would suggest that the team use frequent reflection to try to push in this direction. ... I have one client who put refactoring
    Message 1 of 4 , Jan 20, 2005
    • 0 Attachment
      On Thursday, January 20, 2005, at 5:12:38 PM, Paul Wilson wrote:

      > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
      > <ronjeffries@X...> wrote:
      > Thanks for the feedback, Ron.

      >> 1. Write code that doesn't need refactoring, by removing all
      >> duplication and other code smells immediately. Learn to recognize
      >> refactorings before they're big. I believe that there are always
      >> signs.

      > Good point. I won't make any mistakes in future (and I'll make sure
      > no-one else makes any either) ;-)

      Excellent. But seriously, I would suggest that the team use frequent
      reflection to try to push in this direction.
      >>
      >> 2. Make a note of a needed "big" refactoring and put it somewhere
      >> where you won't forget it. If the bad code is not slowing you down,
      >> don't do anything about it. If you never work in that part of the
      >> code again, the refactoring wasn't needed.
      >>

      > Scaling up to a team environment - in a separate "product backlog" (or
      > separate big board with user stories?).

      I have one client who put refactoring cards on a separate board --
      not a very big one. As the board gets full, it kind of puts pressure
      on the team to do something.

      I do not recommend treating refactorings as stories or backlog
      items, as they do not have the right kind of business value to make
      me comfortable with that, and because I kind of see them as
      exceptions, error corrections. rather than normal course of
      business.

      >> 3. If you do work in the area and the bad code does slow you down,
      >> see whether you can make a little improvement each time you pass
      >> through, rather than bite the bullet.
      >>

      > <snip 4 & 5 - escalations on 3/>

      > So you're saying if it ain't slowing me down, don't fix it? Anything
      > else falls under YAGNI. That is against my instincts, but I can see
      > the logic - I'll have to ponder on that!

      Yes. There needs to be some balance, of course. And feel free to
      have a couple of folks come in on Saturday to clean things up "off
      the books".

      >>Now then ... it seems to me that what I'm really describing are
      >>points on a continuous curve, not steps in a planned approach. I'm
      >>not sure what to do with that observation.

      > Yes. I was thinking more in terms of try and agree 1/2 day in every 5
      > with product owner for "technical debt" resolution.

      Well, that could help. I know that a lot of teams work that way.
      Certainly even as glorious as I am (sarcasm) I do wind up creating
      technical debt. It may be my upbringing or something, but I want
      technical debt to hurt a bit, not to be made OK. So I'm a little
      leery of the half-day thing.

      But different strokes. And if that's how much time it takes to keep
      the code clean enough to keep velocity steady, then by all means do
      it.

      Ron Jeffries
      www.XProgramming.com
      If not now, when? -- The Talmud
    Your message has been successfully submitted and would be delivered to recipients shortly.