49480Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)
- Dec 2, 2010On Wed, Dec 1, 2010 at 6:39 PM, Malcolm Anderson
>If you were going to make that business decision you would at least
> There are a lot of reasons for taking on short term
> technical debt. I use the analogy of the credit card with a 36%
> interest rate. You do not want to use that card. But there are times
> when it makes great business sense to use that card in a short term
want to know:
1) How much am I spending?
2) How much interest will I incur? Over what period of time?
3) Will I have enough revenue to pay it back?
When teams voluntarily take on technical debt they rarely (if ever)
know the answer to even one of these questions.
The interest we are talking about is much higher than you think. It is
more analogous to a loan shark than a credit card. I have seen teams
create enough of a mess in a single two-week Sprint that they were
never able to fix it. I myself am only able to fix the messes I make
with a reasonable amount of effort if I do it within a few days. After
a few weeks the effort is an order of magnitude higher than the
< beating a dead horse >
This is not what the technical debt metaphor was ever intended to
address. Even when we do the best job possible our understanding of
the problem evolves over time. We have to go back periodically and
refactor the code to represent our *current* understanding of the
problem. If we don't then our understanding and the code will continue
to diverge until the code becomes very hard to maintain. *That* is
what technical debt means. Neither Ward Cunningham (the originator of
the metaphor) nor anyone who understood him ever said that writing
crappy, untested code is sometimes a good business decision.
< / beating dead horse >
- << Previous post in topic Next post in topic >>