Re: [scrumdevelopment] Re: Technical Debt Measurement
- 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
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
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 thinkYes. I agree that we need to look at the current real impediments.
> 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.
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.
Example isn't another way to teach, it is the only way to teach.