We need a catchy (ie understandable / memorable to non-technologists or very senior executives) name for Type B Debt. That might prompt a few more questions about it from “the business” to the “IT people”? I’ve sometimes heard “holistic” or “system” risk, but neither of those sound threatening enough to motivate action. I also wonder if Type B debt is a good place for NEDs to challenge (constructively) Boards or CEOs?
1. Upon starting to read this sentence, "Failures in budgeting, bouts of costly organisational transformation, and shifting priorities, can lead to periods of underinvestment," I was momentarily expecting it to end with something about the whipsawing of software production functions, faster than they transform priorities into solution, leaving diverse remnants and working legacy elements of, often many, never fully stabilized past projects scattered across the code base. Is this actually a thing?
2. At least in government, it's often even worse: software production functions are not just whipsawed by (sometimes uninformed) decision making in other parts of an organization; they have to operate in politically hostile environments, with adverse political force actively against the achievement of the system goals -- because success would be a strategic political defeat for them.
A case study is the Obamacare Health Insurance Marketplace roll-out. Deep political opposition to success in any governmental intervention in the healthcare sector was utterly determined to kill that system and thus score a major political blow against the Obama administration. That project was under withering, non-stop, political heavy bombardment.
It worked. The administration's most visible technical undertaking upon delivery was instantly seen to be technical joke and a political monstrosity that profoundly damaged the case for government intervention in the US healthcare marketplace. From the outside it looked like "Government Can't Do Anything Right."
How do the processes that drive change dynamics in priorities, requirements, constraints transform into different regimes for the accumulation and management of TD? Then how does all feeds risk-based decision making about whether and if so how best to take such projects forward?
The Obama team had no viable option to cancel, and had a hard deliver deadline. In the end that project was so compromised that it delivered a technical joke and a political monstrosity.
Fred Brooks famously advocated for design dictatorships to maintain conceptual integrity in design and operation. While such management structures are constructable in private industry, it's hard to create and sustain them in a democratic society with its rapid executive turnover.
In other words, the A/B distinction in TD types and contexts we might suggest the need for signfiicantly different ways to value and manage projects?
We need a catchy (ie understandable / memorable to non-technologists or very senior executives) name for Type B Debt. That might prompt a few more questions about it from “the business” to the “IT people”? I’ve sometimes heard “holistic” or “system” risk, but neither of those sound threatening enough to motivate action. I also wonder if Type B debt is a good place for NEDs to challenge (constructively) Boards or CEOs?
I once massively overly used the financial debt metaphor on technical security debt - https://github.com/ajaquith/securitymetrics/blob/master/content/attachments/2012-03-05-Software-Security-Austerity.pdf
Very interesting paper. Security debt is an area that clearly merits further attention and modelling.
Lovely piece. Two quick comments.
1. Upon starting to read this sentence, "Failures in budgeting, bouts of costly organisational transformation, and shifting priorities, can lead to periods of underinvestment," I was momentarily expecting it to end with something about the whipsawing of software production functions, faster than they transform priorities into solution, leaving diverse remnants and working legacy elements of, often many, never fully stabilized past projects scattered across the code base. Is this actually a thing?
2. At least in government, it's often even worse: software production functions are not just whipsawed by (sometimes uninformed) decision making in other parts of an organization; they have to operate in politically hostile environments, with adverse political force actively against the achievement of the system goals -- because success would be a strategic political defeat for them.
A case study is the Obamacare Health Insurance Marketplace roll-out. Deep political opposition to success in any governmental intervention in the healthcare sector was utterly determined to kill that system and thus score a major political blow against the Obama administration. That project was under withering, non-stop, political heavy bombardment.
It worked. The administration's most visible technical undertaking upon delivery was instantly seen to be technical joke and a political monstrosity that profoundly damaged the case for government intervention in the US healthcare marketplace. From the outside it looked like "Government Can't Do Anything Right."
How do the processes that drive change dynamics in priorities, requirements, constraints transform into different regimes for the accumulation and management of TD? Then how does all feeds risk-based decision making about whether and if so how best to take such projects forward?
The Obama team had no viable option to cancel, and had a hard deliver deadline. In the end that project was so compromised that it delivered a technical joke and a political monstrosity.
Fred Brooks famously advocated for design dictatorships to maintain conceptual integrity in design and operation. While such management structures are constructable in private industry, it's hard to create and sustain them in a democratic society with its rapid executive turnover.
In other words, the A/B distinction in TD types and contexts we might suggest the need for signfiicantly different ways to value and manage projects?
What an interesting response. Thank you.
I'd add there is a big element of trust here. Caveat emptor!