While programming we continually make decisions about the future. An important skill is deciding which decisions to make when. This deciding about deciding confuses many people even programmers.
# Decisions
In the 1980's I threw myself into the then new discipline of object-oriented programming where a small change in thinking had many surprising benefits. One that was often missed was that I could use its modeling versatility to create new options for when decisions must be made.
Many people advanced theories about design in the context of object. Most of these revolved around capturing the diversity present in the physical world. This advice was occasionally useful but not nearly as useful as using objects to capture diversity in the work in front of me, programming.
I felt that I had discovered something important. Objects offered a new kind of modularity which let me compartmentalize the decisions in front of me. This worked especially well on a team where the objects embodied these decisions which became common knowledge among my colleagues and made discussions of priorities effortless.
The most tangible consequence of using objects to model our own progress was that progress continued smoothly month after month, year after year. The program got better every day, more flexible, easier to improve, free of looming disaster.
# Metaphor
We struggle to explain what goes on within our heads as we make the long strings of compounding decisions required of any engineering discipline. The material we work when programming is so light and readily available that our own thinking completely dominates schedules unlike any other form of engineering. Decisions take time but little else.
We often speak of time as if it were money. We spend time with our kids, or save time with a new skill. We wish we had more time when we don't. We say time is money even when we know they are different. We speak of time metaphorically as money and the metaphor mostly works.
Time is literally money to entrepreneurs. They race to market having borrowed other people's money and share the returns when they succeed. The terms are clear: they win, they share, they lose, the money is gone.
The debt metaphor is simple. Decisions take time. Time is money. Delaying decisions is borrowing money.
The parts of this metaphor that eludes people is that taking on technical debut is a strategy. But it can only be good strategy when you understand how to use it to makes software better.
# Technique
I must now explain what it is like to move programming decisions around using objects and how these choices become strategic. How we properly borrow time.
Imagine the conversation between two developers as they make and discuss decisions about their work. They talk about what might be expected and how they will coax the machine to meet those expectations. Let's call this the work. But there is lots more talk, lots more to be decided. There is meta work, the work about deciding how to go about the work. They are deciding about deciding.
The developer's conversation will turn to how much they know about expectations, how they could learn more, how they will know when they have learned enough and when they should stop putting what they've learned into the program. Remember, they are making decisions about the future and the future is always uncertain.
When working with objects developers in this fix always have an easy way out: decide now to have multiple kinds of objects where some can be program now with other variations to come later. This buys time to move on to other important work.
Eventually there will be a clear need for the work that has been left undone. A second or third version of the object will be reasoned about, decided, and put in place. There is more meta work now: can the first version be discarded? If not, can it meet an expanded interface of the later versions? At what cost and benefit?
To employ the debt strategy is to become good at these decisions too. To have skills at meta work.
Some programs are piles of poor decisions and their owners speak of technical debt as if this bankruptcy is what I was trying to explain. They missed my point. They may be incapable of getting my point because they don't understand method dispatch, have never used it to model uncertainty, or maybe don't get where programmers spend their time.
# Reflection
One might wonder if they have the skills to borrow time as I have described. I say probably not. They are programming skills applied in one's stream of thought while making programming decisions balancing the present with the future in intricate situations.
I have described the technique as a conversation between two programmers in the act of programming for a reason. Pairing encourages meta work while the work progresses. What problem are we trying to solve? When are we really going to need that? Will we remember that when we come back later?
These conversations did not happen before there were object to which they apply or before there were screens large enough and programming fast enough for colleagues to see it happening. Then the work and the meta work could be articulated, pointing at the screen, finding words for what happened, remembering these words, and building on them skills and experience.
.
See also Quantifying Technical Debt