Software delivery solvency and subprime technical debt
Software delivery solvency is the ability of the IT department to deliver working services that fulfill a business need in a timely fashion. An example of delivery insolvency is the original Obamacare program.
A key factor in delivery insolvency is that software naturally deteriorates over time because of initial kludgy shortcuts, changing and misunderstood requirements, misaligned and misunderstood technical architecture as well as a changing business and technical environment. The deteriorated code becomes so complex and brittle that any attempt to change is so expensive as to render the code difficult to maintain and almost unmodifiable. Legacy is one example of insolvent code, but there are many examples of code becoming insolvent long before it is legacy..
Technical debt describes the cost accrued by code deterioration, and the standard way to repay that debt is refactoring. Refactoring is the act of redesigning code so that it has the exact same functionality and interface, but an improved more robust internal structure that both meets the current requirements and lays the groundwork going forward. Just like in nature this cycle of deterioration and renewal is what keeps software viable. For example gcc (the GNU c compiler still widely used today) dates to 1987 – almost 30 years old.
In finance, some debt is more risky to the lender and more costly to the lendee – usually loans given to people who may have difficulty maintaining the repayment schedule. We believe that the equivalent type of debt is “delivery debt” – essentially problems in the code or architecture (i.e. technical debt) that affect delivery rather than functionality. Because delivery is an after thought in most organizations (which DevOps is trying to fix) – most development organization are happy to take shortcuts with respect to the “deliverability'” of their code. They leave it to Ops to sort things out – and it is not unusual for Ops to have to work around the same bugs for multiple releases. This type of subprime debt causes code to deteriorate and become insolvent much faster than normal debt.
A real life example of technical debt causing insolvency is of a telecommunication company that wanted to introduce prepaid SMS packages but the billing system architecture assumed that SMS is a part of standard billing. It required months to change the architecture and code such that it allowed of a prepaid model.
Agile and test driven development (TDD) can be useful software development paradigms, but there is no doubt that agile and TDD can cause weaker software solvency and can encourage development of subprime software products.