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.