Re: [scrumdevelopment] Re: Technical Debt and the Product Backlog
- On Thursday, January 20, 2005, at 5:12:38 PM, Paul Wilson wrote:
> --- In firstname.lastname@example.org, Ron JeffriesExcellent. But seriously, I would suggest that the team use frequent
> <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
> Good point. I won't make any mistakes in future (and I'll make sure
> no-one else makes any either) ;-)
reflection to try to push in this direction.
>>I have one client who put refactoring cards on a separate board --
>> 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?).
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
>> 3. If you do work in the area and the bad code does slow you down,Yes. There needs to be some balance, of course. And feel free to
>> 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!
have a couple of folks come in on Saturday to clean things up "off
>>Now then ... it seems to me that what I'm really describing areWell, that could help. I know that a lot of teams work that way.
>>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.
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
If not now, when? -- The Talmud