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

50471Re: [scrumdevelopment] Re: Technical Debt Measurement

Expand Messages
  • Adam Sroka
    Mar 3, 2011
    • 0 Attachment
      There seem to be multiple, diverging definitions of technical debt. This is disturbing, because it makes it a lot harder to talk about, let alone measure. 

      As some of you may know, Ward's original definition of technical debt was meant to reflect the fact that we are driving towards a moving target. We build the best system we know how to today, and nonetheless as our understanding of the domain evolves it diverges from what we wrote in the code. Ward suggests that we should refactor the code to reflect our /current/ understanding, and that if we don't we will be slowed down by this divergence. 

      This isn't what most people seem to mean by technical debt, though. Most people seem to be saying that anything undesirable about our design which could be refactored is technical debt. This is a potentially useful definition, and we could even measure this with some of the design metrics that others have talked about (Although no design metric perfectly reflects the quality of a design. There is always a subjective element to it.) 

      Despite its usefulness, this definition becomes troubling to me when it is used to justify making questionable design decisions now in favor of refactoring later (In effect, borrowing against our technical credit. We haven't quite beat the metaphor to death at this point.) I assert that it is a good idea to always create the simplest design we know how to. It takes considerable skill to make poor design decisions now and then be able to fix them later without spending much (much) more than we would have by just doing the simplest thing in the first place. 

      What is perhaps a bit more troubling to me is that I am now hearing a third potential definition for technical debt: any technical choice which reduces our velocity. This is actually a useful idea, but it becomes difficult to work with when we consider all of the different kinds of technical choices that can have an effect. 

      Is language choice a kind of tech debt? Is framework choice? Is database choice? Certainly I can have a much higher velocity if I create my simple data-driven web app using Rails than if I create the same app in COBOL (With Rails much of what I need is generated for me by convenient rake tasks. With COBOL I have to compile and link just to run a single unit test.) 

      We could come up with separate terms for each of these things, but I think it makes more sense to consider something like Theory of Constraints for managing this. If I need to be able to go faster then I should look for the biggest impediment to that first. It might be that language or framework choices are slowing me down. It might be that poor design is slowing me down. Or, it might just be that I am putting off refactoring longer than I really should. 

      On Thu, Mar 3, 2011 at 5:31 PM, JackM <jack@...> wrote:
       

      The impact of technical debt is that it slows teams down. So I think velocity would be one way to measure this. If your velocity starts tanking then you know you have have problems which might be technical debt. Closure phase starts taking longer and longer.

      Jack
      www.agilebuddy.com



      --- In scrumdevelopment@yahoogroups.com, Geetha Anand <reachgeethaanand@...> wrote:
      >
      > HI,
      >
      > I would like to know how Technical Debt is usually measured and reported
      > and how it is used.
      >
      > Thanks
      > Geetha
      >


    • Show all 14 messages in this topic