I’ve been thinking about a lot of things in terms of debt recently, and the world looks a bit different if you do that. Debt is borrowing against the future, be that in time, money, energy, health, etc. Debt is what you get when you take short cuts, as you are borrowing from the future.
When your debt is money, it’s somewhat easy to understand. You take money from the future you which you have to pay back at some point. It’s a little harder to understand in areas that aren’t money.
If you create a new piece of code you are creating both value and debt. Debt is created by taking shortcuts, as the software will need to be reworked to reasonably extend it in the future. You take a short cut now to pay for it later, with interest. Every future feature will take longer until you pay back your debt. Refactoring is really all about paying down debt in a responsible way in software.
Most of the time the right approach is to pay off your debt. The other option is bankruptcy (which we are seeing a lot of this week in the financial world). Software bankruptcy is throwing the whole thing out and starting from scratch.
When I started thinking about software development in terms of debt in the last few weeks, lots of things started to make a lot more sense. Shortcuts are debt. Inconsistent interfaces are debt. Inconsistent coding style is debt. Bad or wrong abstractions are debt. Missing documentation is debt. Confusing APIs are debt. If you want a project to move forward more productively you need to eliminate some of your debt, as it’s what slows people down (green field code is easy, brownfield is hard).
I’d love to hear about other concepts of debt, and what debt looks like in other media besides software. Please post comments if you are so inclined.
It's always more complicated 
Interesting post! It is always tempting to take the easy route in all walks of life, but doing so almost always ends badly if the route was not first evaluated for its “Return on Investment”. It might seem strange to consider an argument with a loved one as incurring debt, but there is certainly a loss if the argument is not resolved… (debt repaid). You could take the concept a step further too… developers who incur debt through bad code will end up with losing credibility with their peers and users of their software… bad credit.
LikeLike
Debt will occur if I keep reading your blog when I should be finishing the final algorithm proof for an assignment due in three hours.
LikeLike
I think this phenomenon applies to teaching as well. If you invest ahead of time — writing and working through assignments, planning and preparing for lectures, designing exams — you will be better prepared to answer questions that come up. Lack of preparation is debt. Assigning homework without working through it yourself is debt. A rambling, confusing lecture is debt, because you’ll have to re-explain everything later.
I think that financially as well as culturally, Americans have a serious problem with debt. Quick fixes, short-term solutions, paying later vs. saving earlier are all major issues that get us into big trouble.
Heather always gets questions in her water aerobics class like “How can I get rid of the flab on my arms?” Besides the fact that losing weight can’t be directed to one part of the body, what her students are really asking is “How can I get a quick fix to accomplish what I want without patience and hard work?” In that case, debt is driving instead of walking, eating fast food instead of healthy food, staying home to watch TV instead of working out, and especially injuring yourself while trying to take on more than you can handle while working out.
LikeLike
I’ll bring it back to coding… and automated tests 😀
Let’s say you don’t write tests at all, then the reduction of debt through refactoring can be scary and time consuming, since you want to make sure you haven’t introduced bugs or broken existing functionality.
Writing tests after the fact is good, it provides you that safety net needed to refactor in the future. This is one way to pay off some of your debt. However it can be “expensive” as you try to figure out the best way to test methods, try to test all the code paths, and so on.
But writing tests before writing code is a great way to minimize the amount of debt in the first place. By writing *just enough* code to pass each test, and no more, you end up with tests covering all your code paths. Your resulting code is easy to test (since testing was considered from the beginning). Now you can refactor quickly and aggressively with confidence, paying back that debt much quicker with minimal interest 😀
LikeLike
Sean,
You are so right about debt. I saw this video on YouTube, it is explaining about how mone is created by banks: http://www.youtube.com/watch?v=50bWUrKAbwU
It is so interesting, expecially the way that the system NEEDS people to go bankrupt to keep working.
LikeLike