Source: http://tech.groups.yahoo.com/group/scrumdevelopment/message/55626 by Ron Jeffries
Do you have your views on technical debt in something that is published? I would love to see that as I think it's a view that does not get enough attention in the industry.
Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.
Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.
If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now.
If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.
When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.
P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.
OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?
We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.
If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements. Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.
Then what do we do about this bad code? I'm glad you asked.
If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment.
If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better.
That is all:
Don't do it.
When we do it, figure out why and stop.
When we do it, leave it alone if it's not in the way.
If it is in the way, clean up the parts we pass through.
You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"
We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story.
That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.
So. Any followup questions?
Ron Jeffries
Source: http://tech.groups.yahoo.com/group/scrumdevelopment/message/55630 by Adam Sroka in response to above:
I agree with what Ron says above, but let me give you a slightly different take and see if it helps:
In TDD we refactor towards a Simple Design. Simple Design was defined by Kent Beck as a design having these qualities:
1) Passes all the tests (i.e. does what the PO wants)
2) Contains no duplication
3) Clearly communicates the author's intent
4) Has no superfluous parts
As Agile developers we value the ability to safely and rapidly make changes to a codebase in order to reflect our current understanding of the product and our customer's evolving needs. Simple Design makes this relatively easy. We just add or modify tests and then refactor mercillessly until we are satisfied that we still have a Simple Design.
Technical debt can mean a number of things and I find discussing it with people difficult. So, I take a slightly different tac nowadays. Instead I talk about safety.
If we don't refactor mercilessly to a simple design we eventually slip into maintenance mode. Maintenance mode is where good programmers go to die. More explicitly, code is hard to maintain when it exhibits any of the following properties:
1) Untested
2) Contains duplication
3) Obfuscated
4) Has superfluous parts (often in the form of Speculative Generality)
This code is unsafe and must be fixed. Your life will be much simpler if you learn to work in a way that addresses these issues prior to the end of each Sprint. I have seen teams be successful carrying a limited amount of this crap from Sprint to Sprint, but IMNSHO even the best XP programmers I know don't get away with it as well as they think they do.
Hope that helps,
Adam