Twitter Updates

    follow me on Twitter

    Feeds & Email

    • Feeds and Lists
    • FeedBlitz
      Enter your Email

      Powered by FeedBlitz
    Blog powered by Typepad


    « Carnival of Enterprise Architecture #13 - December 2, 2008 | Main | One Reason We're In A Recession... »


    Kurt Häusler

    "One thing about technical debt that often gets overlooked is that it cannot be reasonably measured or estimated until it has been incurred - that is, after the fact."

    That's true for legacy code, but I think for new code, written by a team aware of technical debt, technical debt should only be incurred on purpose.

    We should always ask why technical debt was incurred, for legacy code the answer is usually "because we didn't know any better", but once a team is aware of technical debt, everything changes. You should always be able to go back and assume that technical debt was incurred for some reason, and that before someone made the decision to incur it, they were able to estimate the size of it.

    (Incidentally I am a fan of measuring TD in story points if you already work in a system that uses stories and story points; the interest is included in the stories that are made more expensive by the TD, paying back the principal is a separate story)

    Traditionally software quality management has always had to rely on "after the fact" measurements, such as testing and bug-fixing and I think technical debt management represents a possible avenue into "before-the-fact" software quality management.

    Debt Help

    Hey, nice job on the blog here. Some good ideas. Keep up the good work.


    disagree with some points but overall good article. thanks!

    The comments to this entry are closed.