All too often we slap together solutions in the name of finishing on time. This has been described as incurring technical debt:
Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.
I think programmers intuitively feel this is correct. Good ones learn where the cutoff is, bad ones either create piles of technical debt, or paralyze their shop in the quest for gold-plated code.
One of the insidious things about technical debt is that eliminating it is more complex than just paying of financial debt + interest. There’s a psychological component that can sometimes hide the debt entirely.
For example, in a rush, Flavio crams in a complex but crude workaround to a problem. His solution gets the job done, but it’s complexity hides the fact that he has broken the object model and implemented a really crummy design.
Over time, this kludge is mistaken for “the way we do it” by other developer who come across the design. They reinforce it by building upon it, oblivious to it’s rotten nature.
When Flavio peeks back in and sees the horrible mess built upon his once-tactical hack, he runs for the hills. The technical debt has ballooned into some kind of sick nerd reverse-mortgage crisis.
Normal debts have creditors who are very good at informing their debtors of exactly how much is owed. Software doesn’t extend us that courtesy.
We’re kind of on the hook for keeping track of our own technical debt, which means we need to be disciplined and pay things off as soon as possible.