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

49480Re: [scrumdevelopment] Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • Adam Sroka
    Dec 2, 2010
    • 0 Attachment
      On Wed, Dec 1, 2010 at 6:39 PM, Malcolm Anderson
      <malcolm.b.anderson@...> wrote:
      > 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
      > situation.

      If you were going to make that business decision you would at least
      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
      initial investment.

      < 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 >
    • Show all 28 messages in this topic