Hi Josh,
> I'm glad you said how *people* approach code, because it's a much
> larger
> issue than just what programmers do.
>

I'm not sure who you have in mind, but... if the people *touching* the
code don't have a handle on technical debt, nobody does. "What
programmers do" is too big a deal to warrant that little word "just".

Now, assuming programmers who *do* have their wits about them, you
still need to communicate to other constituencies about what the
programmers are seeing directly, and help them act effectively on that
information. That includes people in testing (or QA if it's called
that), product owners who are dealing with the business side of those
risks, and so on.

But you can't short-circuit the programmers. That doesn't keep people
from trying - there's this old fantasy of "tools that measure
technical debt just by parsing the source code". This is the too
common fallacy of reification, of assuming that because you have a
concept of "technical debt" it's something objective, "out there",
that you can measure the way you'd measure oxidation of metals. That
doesn't work, because what we're dealing with is relational - it's
about how well a specific bunch of programmers with specific tools and
habits are able to deal with a specific code base.

A really, really bright idea from one of my friends, Regis Medina, was
to apply the techniques of usability testing to source code, and more
broadly to consider source code "the programmer's UI onto the
project". Unfortunately he's been too busy recently to develop it much
further but I think it has legs. (As has the related transpositon of
"process as the manager's UI onto the project".)

Another thing I think is cool is Coding Dojos, not so much for what
they are but for the directions they point in. For instance, some
research into pair programming suggests that it's not so much the
pairing that is effective, but rather the act of "programming out
loud". Dojos tap into that as a way of teaching programmer skills.

> We may only get one huge step forward, like TDD, every decade.

That shoudn't keep us from trying. How long does it take to have an
innovative idea? If you have enough of them, sooner or later you'll
hit on a game-changer. I've been fooling around with a technique known
as the "zwicky box", but there are others that might work,
brainstorming and so on. Back in the early oughts, as I remember it,
there was a lot of such kicking ideas around going on, and things seem
to be a little more tame of late, possibly because of entrenchments of
the Agile "vehicles" as you call them, and the money involved, and so
on. I'd like to see that creativity come back.

Cheers,
Laurent Bossavit
laurent@...