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

50472Re: Technical Debt Measurement

Expand Messages
  • JackM
    Mar 3, 2011
    • 0 Attachment
      I believe Ken Schwabber in his google tech talk talked about technical debt and in particular made reference to "Core or Infrastructure software" where essentially new functionality is throttled by the the core software, core software basically, riddled with technical debt, un-refactored code etc. so Velocity in the core is way lower. Also references Design Dead software!

      Check it out...



      --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
      > 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