Published in


Software Fatigue

This post proposes a metaphor for software engineering: software fatigue. First I’ll talk briefly about the role of metaphor in software engineering, and then I’ll talk about the proposed metaphor.

Metaphors in software engineering

In “Metaphors We Live By”, Lakoff & Johnson argue that humans use metaphor to understand unfamiliar topics. Through a metaphor, we interpret a new concept in light of an existing one, by mapping the structure of the new concept to the old one. For example, when a government says “We’ll fight a war on COVID-19”, they are metaphorically interpreting COVID-19 as an enemy, and preparing their citizens to look for metaphorical generals (e.g. a government commission), troops (e.g. doctors and nurses), strategies (e.g. social distancing), victories, defeats, and all the accoutrement of war. The choice of metaphor may affect the strategies we take to address the problem, for better or for worse. We might choose some good strategies, but we might also overlook others because they fall outside of the metaphorical framework that was chosen. No metaphor will be perfect, but the use of a reasonably accurate metaphor can save everyone time — we can map it into a known conceptual framework, share a common vocabulary, and “port”/adapt known problem-solving approaches on a new problem.

Perhaps the most famous metaphor in software engineering is that of “technical debt” to articulate the decision to defer a “good” design or implementation in lieu of a “good enough” one. This decision is an engineering judgment, grounded in an estimate of the relative cost of the good vs. good-enough approach (down payment), the anticipated negative effect of the good-enough approach on subsequent design and maintenance (servicing the debt), and the eventual option to redesign towards the “good” approach (paying off the debt). According to lore, Ward Cunningham first proposed this metaphor in 1992 and folks like Steve McConnell and Martin Fowler helped popularize it; nowadays, researchers have found that technical debt is a widely used metaphor that helps engineers “bridge the gap” (look, another metaphor!) between technical- and business-oriented personnel in terms of prioritizing maintenance work within a product backlog. (Footnote: In a YouTube interview, Cunningham said he started using the debt concept after reading Lakoff & Johnson and realizing the importance of a good metaphor).

The metaphor of technical debt has been valuable for the software engineering community. However, I think it is inadequate to talk about the effects of the technical debt on the soundness of a software system. For this, I suggest the metaphor of software fatigue.

Software Fatigue

In “To Engineer is Human”, Henry Petroski reminds us that material fatigue is the root cause of many catastrophes in civil engineering. Material fatigue causes the development of cracks in a structure (or its components) as they undergo stress. A few cracks are fine. Enough cracks, and the components fail. Enough failed components, and the structure fails. Modern structures have some redundancy, but no amount of redundancy can eliminate failure all together.

I propose to transfer the concept of fatigue from other engineering disciplines into the domain of software engineering. This is a metaphor — software doesn’t actually exhibit fatigue like a physical structure. Software does not degrade as it is used; a web form doesn’t get worse as more people click the “Submit” button. But software may degrade as it is changed. As engineers change a software component to adapt to new requirements, the component may become distorted from its original design, making it harder and harder to change and more and more likely for those changes to lead to defects.

Engineers often refer to this phenomenon — distortion as the result of changes over time — as technical debt, but I think this is stretching the debt metaphor too far. Debt is a metaphor for project management (who have taken on the debt), but it is not a metaphor to describe the consequences of the debt in the context of the software product. Debt is a property of the project as a whole, while fatigue is a property of individual components. I suppose we can talk about one component having (being in?) more debt than another, but debt generally does not help us reason about the location nor the criticality of the changes being deferred. The metaphor of structural fatigue might help.

To apply a structural metaphor (in the sense of Lakoff&Johnson), we need to map the elements from one domain to another. Here is a simple attempt, choosing several concepts from fatigue, with credit to Wikipedia for my limited understanding of fatigue.

  • Material fatigue is the result of use (“cycle loading”) — more use means more fatigue. In software, the metaphor predicts that the more a component is changed, the more likely it is to become defective (either within itself, or changing the assumptions of its dependents). Note that the metaphor of technical debt does not let us talk about this idea, except in terms of a “high cost” of servicing the debt. But is this “high cost” in engineering time (it takes longer to make a change), or in terms of defect proneness (the changes are more likely to lead to defects)? The debt metaphor doesn’t help us — the fatigue metaphor does.
  • Some environments may lead to greater material fatigue than others, e.g. depending on the temperature. In software, the metaphor predicts that some changes will have a greater impact on the reliability of a software component than others will. Again, I think a debt metaphor does not help us think about this in our software projects.
  • Material fatigue is stochastic — different, seemingly-identical components wear out at different times along a distribution. In software, the metaphor predicts that different software modules exhibit different defect prone-ness as the result of changes, but along a predictable distribution. Nothing about the metaphor of debt would cause us to reason about defect prone-ness, but fatigue does.
  • Material fatigue can be observed — you can see the cracks form before the component fails. In software, the metaphor predicts that a software component’s “cracks” can be measured prior to its failure. Specifically, defect prone-ness can be predicted, e.g. using software structural metrics such as module connectivity or cyclomatic complexity. The technical debt metaphor does lead us to attempt to measure our debt, but only from a financial efficiency perspective. The fatigue metaphor makes fatigue measurement imperative in order to anticipate failures.

Like all metaphors, the metaphor of fatigue is imperfect when applied to software. Here is an example: material fatigue is irreversible, while a “fatigued” software component can be repaired.

What do you think?

I welcome discussion in the comments section. Do you think that the metaphor of technical debt is sufficient to capture the ideas presented here? Do you think the metaphor of material/structural fatigue is helpful? Would you suggest another metaphor to help the software engineering community think about these ideas?



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
James Davis

I am a professor in ECE@Purdue. My research assistants and I blog here about research findings and engineering tips.