On Aug 27, 2011, at 5:09 PM, avi_a@...
Looking back at what I wrote in reply to Ron, I realize that the term "technical debt" may be misleading here too.
Although we're talking about refactoring, it's not the regular simple refactoring that takes place (or should take place) throughout coding, but rather about a new technical needs that might arise - be it changing the database schema, learning a new coding
technique, setting up a new build server etc.
Calling this "debt" in the first place makes an assumption that these needs might have been avoided "if the team did what they should have" - which is starting to smell like throwing responsibility over the wall...
In fact, I think that Ward Cunningham's original use of the term "technical debt" covers this situation. Technical debt exists whenever the actual design of the system deviates from the design we now understand to be ideal. Ward seemed to have primarily in mind the fact that our understanding of what a good design is emerges from doing the work. The code grows and grows and at some time we realize there is a better way.
If the code grows and is maintained well, that is, with suitable automated test scaffolding, with generally clean, well-factored code, and so on, it is
usually relatively easy to accommodate our new design ideas and the system shrinks to a newer, nicer form.
Two of the things you mention, a new schema and a new coding technique, seem to me to fall clearly under Ward's original definition. Both of these, in addition, can -- and in my opinion should -- be done incrementally. Whenever we see an improvement to the schema, we should put it in. Whenever we learn to code better, we should begin to code better. Sometimes we naively think that the new schema or new technique "changes everything". In my long experience, this is almost never true. It is almost always possible and quite practical to make the changes incrementally. (By "almost always", I mean that as far as I know, it is always possible but sometimes I haven't seen how until too late.)
A new build server is a more interesting situation. It may be that the old build is slowing us down, by being
unreliable, needing a lot of hand holding, making it hard to test things. We want to do the new build server because it will help us in the future. A new build server isn't a repayment of a debt so much as it is an investment!
Now, Dan would probably say, sure, it's a technical story, put it on the backlog and prioritize / order it. Yes, but if you do, it is very difficult for the PO to compare it to a new feature because the build server may give her new features at some future time, but right now it takes features away. If "technical debt" is deferring important technical work to buy more stories, then this is like "business debt", deferring important stories to buy some technical capability.
It's easy to say, put it on the backlog. If we do, it's hard to prioritize. It's easy to say, take X percent of your technical time and do it because it is part of the team's job to do the
work "right". If we do, we are taking away some amount of the PO's ability to steer the project by selecting features.
It's a dilemma, and I don't see a single right answer.
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
-- Tom Jeffries