Why Good Software Goes Bad
Central idea
Software quality follows the process that creates it, and a process can improve only when the organization observes reality and changes its behavior.
Summary
Software failure is a mismatch between expected and observed value produced by requirements, resources, randomness, process, management, and culture together. Henrichs describes four process patterns. An oblivious process fits tiny personal work. A variable process relies on individual heroes. A routine process uses plans and controls but may follow them blindly when conditions change. A steering process observes actual state, compares it with intent, and corrects course. Because software work is nonlinear, early progress cannot simply be extrapolated and individually successful parts do not guarantee a successful whole. Teams need explicit models, visible work, and small frequent governing actions.
Key ideas
Named practices are not mechanisms
Saying Agile, Lean, or another label does not import the feedback and decision principles that made the practice useful.
Software work is nonlinear
Interaction effects, difficult late work, and accumulated risk make straight-line prediction unreliable.
Steering requires observation
A plan becomes a control system only when people can see real state, compare it with intent, and act on the difference.
Four process control models
Oblivious: one person and a problem that fits in one head.
Variable: outcomes depend on individual heroes.
Routine: plans and controls seek repeatability.
Steering: feedback changes process as reality changes.
Why it matters now
AI increases output without making organizations linear or predictable. Teams need better feedback and governing models, not simply more pressure or a new named process.
Continue with the original
This short version preserves the main argument. Follow the source for the complete talk, article, or book.