Wow!  I've not really looked at a decision to "do the quick fix" or to "do the correct fix" like that.  It makes total sense though.  I remember learning early on that the cost of fix grows exponentially the later it is found.  I guess that is saying the same thing but in a different way.  Great post Jeremy.  It's one of the better reads I've had in the last week or so.

I guess the hard part, for me anyway, is that I'm not normally given the time to fix the big picture of the problem.  We fix the issue/bug and move on.  You can see that a whole process or piece needs to be reworked and can see yourself coming back to it again at a later date.  Being proactive is a good start though - do a little at a time when you see it.  Jeremy proceeds to give us a checklist to use as we code to look out for opportunities to pay down some of that debt.  If you use ReSharper, he gives ReSharper shortcuts to speed the process.  These are just additions the reasons why I like ReSharper.