Last updated on June 15th, 2021 at 02:55 pm
Defining technical debt at the level of specificity needed for project objectives is difficult. Confronted with this difficulty, some internal customers of technologists adopt a zero-tolerance approach to technical debt, without specifically defining technical debt. Post-delivery—sometimes much, much, post—when technical debt is discovered or recognized, technologists are held responsible, even in cases when no one could have predicted that a specific artifact would eventually come to be regarded as technical debt. This sets up an adversarial dynamic between technologists and their internal customers.
And that’s when the trouble begins.
Within this adversarial dynamic, technologists try to protect themselves against future recriminations by “working to rule.” They perform only work that is specified by the internal customer. If they find something additional that must be done, they perform that work only if they successfully obtain the customer’s approval. Some customers continue to adhere to a zero-tolerance policy with respect to technical debt, but such a non-specific requirement cannot be met. Because technologists are “working to rule,” they use the ambiguity of the zero-tolerance requirement to assert that they performed all work that was sufficiently specified. This level of performance is analogous to the work-to-rule actions of some employees involved in labor disputes with their employers, and who are literally in compliance with the requirements of the employer, but only literally [LIBCom 2006].
Requiring deliverables to be totally free of technical debt contributes to formation of an adversarial culture, wherein the adversaries are the technologists and their internal customers. Shedding that adversarial culture, once it sets in, can be difficult. Compelling employees, vendors, or contractors to deliver work that’s free of all technical debt is therefore unlikely to succeed. Whether work is performed in-house by employees, or is outsourced, or is performed in-house by contractors, deliverables that meet the minimum possible interpretation of the objectives of the effort are almost certainly burdened with unacceptable levels of technical debt. What can we do to prevent this?
To avoid creating an adversarial culture, we can specify in project objectives some kinds of technical debt that must be removed in toto. To ensure steady progress in technical debt retirement, develop a statement of objectives that includes complete retirement of at least one well-defined class of technical debt, emphasizing debt classes that have the highest anticipated MICs in the near term. Other well-defined classes of technical debt can be addressed on a best-effort basis.
We must accept that any other forms of technical debt that remain at the end of a given project, or any constructions that later come to be recognized as technical debt, are just the “cost of doing business.” We’ll get to them, but unfortunately, not this time.
Available: here; Retrieved: May 9, 2017.
- Nontechnical precursors of nonstrategic technical debt
- Failure to communicate long-term business strategy
- Failure to communicate the technical debt concept
- Technological communication risk
- Team composition volatility
- The Dunning-Kruger effect can lead to technical debt
- Self-sustaining technical knowledge deficits during contract negotiations
- How performance management systems can contribute to technical debt
- Stovepiping can lead to technical debt
- Unrealistic definition of done
- Separating responsibility for maintenance and acquisition
- The fundamental attribution error
- Feature bias: unbalanced concern for capability vs. sustainability
- Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma
- Confirmation bias and technical debt
- How outsourcing leads to increasing technical debt
- How budget depletion leads to technical debt
- Contract restrictions can lead to technical debt
- Organizational psychopathy: career advancement by surfing the debt tsunami
- The Tragedy of the Commons is a distraction
- The Broken Windows theory of technical debt is broken
- Malfeasance can be a source of technical debt