I had the pleasure of catching up with Jim Highsmith recently and we had an interesting discussion on the topic of technical debt.  We were talking about the non obvious consequences to high technical debt loads.  One particular insight that rang true from my own experience was the effect of high technical debt loads on the psychology and mind set of an organization and in particular, the tendency for an organization to actually underperform beyond the level that might, on the surface, be dictated by the technical debt load.

After an organization experiences extended periods of high technical debt, the decision making processes of the software’s stakeholders often begins to change.  Faced with repeated instances where the inflexibility, fragility, or speed to augment or change the software has caused the organization to fail to capitalize on a new opportunity or respond to urgent change, stakeholders slowly start to form a mental model of the software’s limitations.  Typically, this model is a darker, more pessimistic view than reality.  Also, they typically has an inaccurate view of the actual limitations imposed by the debt load.  These inaccuracies get anchored more to circumstances where failure has occured more than they are informed by architectural of quality limitations of the code base (though there is, of course, a strong enough correlation to reinforce this model in the stakeholder’s mind).  

Unfortunately, as the mental model solidifies, stakeholders consciously (or subconsciously) begin relying on their internal model of the softwares limitations and the organization’s ability to respond instead of soliciting the development team’s opinion or engaging the organization’s formal product management process.  Often, the product managers fall into the same pattern, no longer consulting the developers or architects for estimations.

The consequence of this behavior is a systematic underperformance of the organization.  Opportunities are overlooked or passed on, even when a percentage may have been achievable by the organization despite the technical debt level of the software.  This leads to an interesting dysfunction in the organization where the perception gap where the organization underperforms the current state of the software and development teams begin to defend their code base, objecting to the characterization by the business.  This incentivizes both sides not to invest in technical debt reduction as the development team loses credibility defending the perception gap and the business refuses to support or fund technical debt reduction because of lack of confidence in the organization’s ability to execute.