Military Systems + Process = Technical Debt

I was just reading through the literature on Technical Debt (see Ward's Technical Debt). I like these definitions of Technical debt (from Construx) : 

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)

to quote Martin Fowler (Fowler TechDebt) "The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments." Leading to the Red Queen effect: running to stay in place or falling slowly behind. 

But there is a third cause of technical debt, process debt.

Process debt occurs when an organization is so process laden that they are unable to develop or deploy a software system that has any hope of being current or of meeting current needs. Many larger Defense systems fit this mold: the shear mind-numbing process of how to create these systems from design to RFP to contract award virtually ensues that the system when and if its completed is Legacy. 

the fix to military acqusitions will be painful, not quite sure when the healing will start