Grand Rapids Perl Monger Matt Heusser is organizing a workshop on technical debt in August. A recent blog posting from Matt gives some great talking points about technical debt, including one angle I hadn't thought of before, probably because I haven't taken any programming classes in over 20 years:

Our educational system, for the most part, is built on one-off projects. Students build a program that inventories their CD collection. It doesn't work well - it even has some bugs - but it is good enough to demo and get a B+.... [They] can get hacked out in a weekend with a lot of pizza and caffeine....[S]tudents never have to live with the pain of maintaining the pile of mud they write. Thus, our first exposure to programming actively rewards us for tech debt.

There's a lack of training, perhaps, but is programming leadership at fault as well? The old management saw of "What gets measured gets done" holds here. If your performance review is based on getting things done (for some value of "done") by a deadline, you're going to go aim for that. Heck, you can turn to daytime television sage Dr. Phil for this one: People do what works.

I'm dealing with that right now. I've got a code base where the previous programmer's #1 goal was apparently to complete the task as quickly as possible. I've got PHP code like this: 

$rslt=pg_exec($conn,"drop table keys1x");
pg_freeresult($rslt);
$rslt=pg_exec($conn,"drop table keys2x");
pg_freeresult($rslt);
$rslt=pg_exec($conn,"drop table keys3x");
pg_freeresult($rslt);
...
$rslt=pg_exec($conn,"drop table keys13x");
pg_freeresult($rslt);
$rslt=pg_exec($conn,"drop table keys14x");
pg_freeresult($rslt);
# The tables are then recreated with 14 cut-n-paste
# calls of identical CREATE TABLE DDL statements.

Stupid, right? But was it? If your goal is to get a change made as quickly as possible, with no regard to other design factors, then cut & paste of code makes perfect sense. This guy was acclaimed for his ability to turn around program changes quickly, so at least someone was happy, even if that someone wasn't the programmer who followed. As Dr. Phil would say, he did what works.

The causes of technical debt can be varied, and multiple. The programmer might not know better. It might be what worked best for him in a given situation. It could have been the only way out of an otherwise-impossible situation. Whatever the reason, it's best to know why things are the way they are before you try to pay down the debt.