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

50480Re: Technical Debt Measurement

Expand Messages
  • Matthew
    Mar 4 7:58 AM
    • 0 Attachment
      --- 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.
      >

      I think it's important to note that tech debt is a metaphor, a thought experiment, not an actual like, thing. So any hard attempt to 'measure' by reducing to a number is going to be measure some attribute (like velocity or complexity), not the /actual/ debt.

      Because there is no actual debt; it is a /concept/. To attempt to make real what is not is a sort of reification fallacy -- which, I feel obligated to add, is the same thing we do with velocity and complexity.

      (In other words, whatever use use to measure velocity isn't actually velocity either, it's some approximation.)

      > 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.
      >

      I had to "well actually" you, but I think when Ward introduced the metaphor he was speaking to the issue of deferring some improvement in order to hit a deadline. You can think of this as sort of "borrowing trouble" - it allows you to go faster /now/ but will cause some penalty in the future, just like real debt. (In addition to refactoring, I think one of the classic examples is failing to upgrade the compiler from c++ to dotnet in 2002; "we'll do that next release. It would take a couple days we don't have right now.")

      Now there are responsible ways to manage real debt. For example, you might borrow money in order to build a factory, with a plan of making money faster than the interest accrued on the debt.

      What you don't want to do is borrow money without realizing you are borrowing money -- which is exactly what happens every time a manager says "JUST HIT THE DEADLINE!" and people make irresponsible compromises in order to hit the deadline.

      So the Tech Debt metaphor can be useful in explaining those tradeoffs to executives, to "speak in their language."

      I feel obligated to add that there is a difference between consciously taking on tech debt and writing crappy code; writing crappy code is just bad.

      In general, though, once we have this conversation, people want to /measure/.

      They want to get out cyclomatic complexity, or take the first derivative of velocity (which is acceleration), or other stuff like that.

      The problem is, once you start measuring and controling, you introduce dysfunction. At the same time, since most of our metrics are either subjective proxies (velocity), or objective proxies (complexity, lines of code), the *numbers* tend to will go up, but, over time, the difference between what you are actually measuring and the desired change becomes greater and greater.

      In the end, I don't recommend quantitative measurement of a metaphor. It doesn't make any sense, and Steve Poling and I dropped our book project. (After serving as the organizers of the Agile Alliance Workshop on the subject.)


      > 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.)
      >

      What I'm saying here is that if you make the decision consciously, transparently, with management informed of the consequence, it might be just fine.

      *That* said, it is *not* okay to do crappy work and blame management. Like a doctor who said his patient "wasn't worried" about him washing his hands and he "needed treatment right now", as professionals we have a responsibility to do work that is fundamentally good. Where we draw that line is a tough discussion.

      My short answer is that the team should have some shared agreement on minimum standards for the code, and /every/ change to the system should be at that level or higher.

      Bob Martin has a book, "Clean Coder", coming out in a few months that discusses that issue in more depth.

      I think I'll stop rambling now. :-)

      regards,



      --
      Matthew Heusser,
      Personal Blog: http://xndev.blogspot.com/
      Test Community Blog: http://softwaretestpro.com/blog/
      Twitter: mheusser
    • Show all 14 messages in this topic