Just Enough Technical Debt

Zero technical debt sounds like a great target to aim for. In my earlier developer days I strongly believed that all projects should go for this target. At a company all-hands I heard from a senior engineer that having zero technical debt is often not what we want. I felt betrayed.

Why is it that zero technical debt isn’t what we want?

Memory Allocation Strategy: Leak All Allocations

Let’s take a moment and think of a hypothetical program. If you knew that your program ran once and terminated, would you go through the effort of deallocating each individual memory allocation at the end? You are about to end the process and drop the entire heap anyway. Cleaning the heap at this point is a waste. For short-lived programs who’s memory consumption is bounded and less than the available memory the more efficient strategy is to just leak all memory.

One might wonder if such a strategy would break reusability. “Leak all allocations” doesn’t mean that you shouldn’t call free() (or equivalent) in your code. It means that the memory manager would treat free() as a no-op. This principal also applies to garbage collected languages. After all, the job of memory management is to simulate infinite memory. If you are only going to use a finite amount of memory then you don’t need memory management.

What Does Just Enough Technical Debt Look Like?

Some of the motivation for stopping short of perfect comes from the Mythical Man Month.

For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out” are essential disciplines for the theoretician.

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

Software projects tend to be characteristically similar. Putting too much effort into a project features you don’t need and polishing up code that nobody will reuse is wasteful. It’s just a little bit harder to know when you’ve crossed the point of diminishing returns where cleaning up the code no longer makes sense.