I had a thought on this early this morning when I was somewhat less than awake.

Although there's no concept of separate lenders in technical debt, we can get something almost as good. When faced with the need to take on technical debt it might be possible to select among several solutions that have different interest rates.

Imagine a problem that we don't have time to solve correctly, but a small amount of brainstorming produces two potential hacks. One is the nightmare you normally get in this situation. The other leaves some wiggle room for a few unit tests or some minor validation code that helps recognize edge cases.

Even though this second solution still increases the technical debt in the system, it has a lower interest rate because it helps to point out the places where it makes maintenance harder.

I have known good programmers who added some kind of trap code in a half-way solution to point out when boundaries were reached. This allowed writing simpler, mostly right code that could be ready now, without incurring all of the problems of the complete hack. When we approached the areas where this solution began to break down, we got an indication that there was a problem and could fix it when needed.

This might even be a good tactic to help mitigate the risks in a quick-and-dirty solution.

Imagine the following scenario.

• The right solution will take a week
• The quick hack will take a day, but will cost a day's effort every month to work around/clean up
• With an extra hour or two of effort, we can think we can reduce the monthly cost to somewhere between 2-4 hours.

It is likely the business side and technical side would see this as a worthwhile investment of extra time.