The debt metaphor in software development

In a new post, Ward Cunningham shares his thoughts on the “debt metaphor” in software development. One of the points he brings out is that programming can be thought of as making decisions now on the functionality of the program and deferring others to a later time (debt), with the understanding that as the program matures, refactoring can occur to make the program more efficient/better (paying back the debt).

In my experience in avionics software development, the creation of software is driven by approved requirements. As requirements change or are refined, the software is updated to be consistent with those requirements. One type of “debt” I see is when functionality is not completed on time, and gets deferred to a later software release (cost increase). Another type is when a problem is found (requirements, source code, tests, documents), but addressing the problem is deferred to a future time (the problem does not impact the functionality of the requirements, source code, or tests, or is deemed not  a safety issue). This type of debt (typically called “open problem reports” (OPRs) is getting more scrutiny by aircraft certification agencies and OEMs (Bombardier, Boeing, etc.), since they see increasing numbers of OPRs as an indicator that the overall “health” of the software may not be as good as it should be, and that there should be as few OPRs as possible (in other words, fix your problems as you find them).

For myself, I prefer to fix problems when they come up. However, when you work as a member of a team, sometimes business decisions dictate otherwise….