Failure Patterns

This chapter is the core of this site.

It describes as Failure Patterns the "ways of breaking" repeatedly observed in software and organizations.

The Patterns addressed here are not root cause analyses or checklists. They are structures that address how assumptions such as decisions, measurement, responsibility, and boundaries collapse and become fixed.

Pattern as Structure

Failure Patterns do not arise from a single error or mistaken judgment.

When multiple Forces such as uncertainty, dispersed responsibility, absence of measurement, and time constraints continue to act simultaneously, a certain behavior stabilizes as a "structure."

The Patterns addressed in this chapter describe structures of failure that appear as a result of such Forces reaching equilibrium without being resolved.

Each Pattern is composed of the following facets:

• Context
• Forces
• Failure Mode
• Consequences
• Countermeasures
• Resulting Context

These are not steps, but facets of the same situation cut from different perspectives.

Core and Derived Patterns

This site organizes Failure Patterns as two layers with different roles.

Core Failure Patterns

A group of Patterns that address the fundamental structures of how things break, such as decisions, measurement, responsibility, and boundaries.

They exist as assumptions in many situations and form the foundation on which other Failure Patterns hold.

• Decision-less Agility
• Metric-less Improvement
• Context-Blind Change
• Responsibility Diffusion
• Boundary-Blind Integration

Derived Failure Patterns

A group of Patterns that address derived forms of breaking commonly observed in practice in environments where Core Failure Patterns are established.

They are close to specific contexts such as technology, organization, and operations, and are easily used directly as diagnostic terms in the field.

• Specification-by-Absence
• Retry-as-Recovery
• Test-Passing Illusion
• Shadow Ownership
• Local Optimization Trap

Relationships Between Patterns

Derived Failure Patterns tend to be more easily observed in situations where specific Core Failure Patterns exist as assumptions.

For example,

• Decision-less Agility and Responsibility Diffusion tend to induce Shadow Ownership and Specification-by-Absence
• Boundary-Blind Integration tends to combine with Retry-as-Recovery and Test-Passing Illusion
• Metric-less Improvement tends to manifest as Local Optimization Trap

These do not indicate causal relationships. They are examples of structural chains repeatedly observed in situations with similar arrangements of Forces.

Intended Readers and Use Cases

The Failure Patterns addressed in this chapter do not assume a specific role or occupation.

The main intended users are those who wish to organize structurally "what is happening" and "why decisions cannot be made" in situations where changes, improvements, or decisions must be made for software in operation.

For example,

• Being asked to make changes without knowing the specifications or assumptions for decisions
• Conducting improvement activities but unable to explain their effects
• Having agreed supposedly, but decisions are overturned later
• Tests and staging pass, but anxiety remains
• Distribution and external integration increase, and the scope of impact cannot be explained

In such situations, the Patterns in this chapter can be used as diagnostic terms.

Patterns do not substitute for decisions. They are guide lines for articulating assumptions, dynamics, and structures in order to take on decisions.

Hints for Use

• When unable to organize what is happening, refer to Context
• When thinking about why it does not stop, refer to Forces
• When wanting to change not how to fix but the assumptions for decisions, refer to Countermeasures

Patterns are not panacea. Use them as reference points for recovering decision-making capability in situations where multiple Forces are in tension.