Hungry and in a hurry, I dropped into the diner and ordered eggs and toast. The server returned shortly with an electric skillet, a toaster, two whole eggs, and two slices of bread. As I cracked the eggs into the skillet, the server came back along the counter with a bag of coffee beans and a grinder, asking, “Want coffee with that?”
At this point, you’re probably questioning my choice of restuarant. Especially if I make a habit of eating there. And what does this have to do with software development?
Deficit Spending
The concept of technical debt is well established by now. In the best case it means buying a near-term benefit by deliberately taking on a future responsibility, as in, “I’l take out a loan to replace my monster truck with a hybrid, and will make the payments out of what I’m saving in gas!” Sometimes we take a short-cut in the interest of advancing a project, but also know that we’ll pay it back later.
It’s more troublesome when the obligation is created by someone who will not have to deal with the consequences. To put it bluntly, separating a decision from its consequences is a recipe for bad design. It is both easier for the decision-maker to add costs and harder for the ones who will bear those costs to see the debt growing.
I propose to borrow the term “deficit spending” to refer to technical debt imposed by someone else. And to keep this from being an abstract rant, will follow with a few additional posts to identify kinds and causes of technical debt spending.
Sliding up the banister 