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

Re: [scrumdevelopment] Re: Technical Debt Measurement

Expand Messages
  • Ron Jeffries
    Hello, Adam. I think you raise a good point here. It would be good to have terms for the various kinds of what we now call technical debt to help us talk
    Message 1 of 14 , Mar 4, 2011
    • 0 Attachment
      Hello, Adam.

      I think you raise a good point here. It would be good to have terms
      for the various kinds of what we now call "technical debt" to help
      us talk about them more clearly. Some random thoughts:

      1. I believe you are correct about Ward's original usage meaning
      a gap between our current understanding and the code's
      understanding of the domain and the suitable design.

      I also believe that I did not understand that until his recent
      writings on the subject.

      2. Then there is "anything undesirable about the design". I agree
      that this is important, and I think that we'll find that there
      are some good things we can say about it, and that some of it
      will elude us and require us to clarify our thinking. I agree
      that some important things remain subjective and I believe they
      always will. At the same time, some very interesting metrics are
      out there.

      3. With you, I am very concerned about the notion of making
      questionable design decisions in the name of speeding up. We have
      probably all tried this, and gotten away with it, in the sense
      that we shipped our code. This does not really tell us anything
      about whether it was a good idea: it only tells us that we did it
      and survived.

      Some name brand people, notably Joshua and Jim Shore, have been
      saying that you can squeeze code quality and get some time out of
      it. I think this is not proven, even for them, and that their
      idea of squeezing code quality and that of their readers are
      probably quite different. I would bet that they don't have a lot
      of 400 line methods even in their worst code.

      4. You mention also other technical choices affecting velocity.
      As you say, language, framework, database, all these things
      clearly affect velocity. I would not be inclined to include them
      in technical debt offhand but I can certainly understand someone
      feeling that some legacy decision had messed them over. A
      decision to use C++ for example. Or Java. :)

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

      Yes. I agree that we need to look at the current real impediments.
      That said, there is, it seems to me, one very common thread, which
      is that many teams create designs which, rather than improving over
      time, get worse. Whether we call that technical debt or code rot,
      it's a big problem.

      Ron Jeffries
      Example isn't another way to teach, it is the only way to teach.
      --Albert Einstein
    Your message has been successfully submitted and would be delivered to recipients shortly.