Technical Debt - VII

The technical debt series took me to an different place that I expected.

I have come to believe that, when it comes to Technical Debt, as an industry ... we have more questions than answers.

Sure, you can use the Nancy Reagan approach and "Just Say No", but the reality is that system factors impact behavior. The motivations to take the quick hack are immediate, positive, and certain, while the negative consequences are delayed and uncertain.

Imagine that you are a technical contributor, weighing your options, considering taking on technical debt. The negative factor is pain later for maintenance or bug fixes. But imagine what goes through your mind -

1) This code might never have to be touched again.
2) If we do have to touch it, I might not work here anymore.
3) If I do work here, we might be able to pass it off to the new guy!

That's a pretty weak negative incentive.

So saying "Just Don't Do It" is a little bit like telling the obese person to diet and exercise. It's technically correct, and yet it doesn't help much. The system factors are hard to beat, but not impossible. Weight Watchers does some amazing things.

How do they do it? Why by finding a way to measure weight and providing certain positive outcomes for success, and support for set backs.

So we need to find a way to quantify technical debt - a way to measure it. We need a way to communicate it to decision makers.

Personally, I believe that half the reason management is so hot to trot about taking shortcuts is that they are invisible. By not being able to measure the consequences of technical debt, technical contributors are doing management a disservice. (And who's choice should it be, anyway? If an administrator were to tell a doctor that he was washing his hands too much and wasn't billable enough, would he stop what he believed to be good sanitation habits?)

Like I said, more questions than answers.

So I have decided to create a completely free, non-profit peer workshop to discuss technical debt. It will probably be two work days long, held in West Michigan. Right now I am securing facilities in the middle August time frame. My co-organizer is Steve Poling; expect a call for participation around the middle of February.

This is not a presentation-style conference. Instead of coming to hear a half-dozen gurus tell you what to do using PowerPoint slides, we will start with a problem (and a bunch of questions) and collaboratively invent some proposed solutions. Then we'll try them and see how they work. The workshop will be by invitation or application only, and will be limited to 15 (at most 20) people.

If you have interest or ideas about the workshop, please feel free to leave a comment or drop me a line.

More to come.