After a previous release was so buggy, the management team added an additional test phase, expecting quality to go up. However, it was unchanged, which left everyone puzzled and management demanding to know why.
We test to improve quality. We are often tempted to add another test phase or quality process, believing that we will reduce the number of bugs in the finished product. But what if adding phases made absolutely no difference to quality?
In this session, we learn of a risk compensation phenomenon known as the Peltzman Effect. We learn why the benefits expected from adding quality processes rarely materialise in the way we expect, but are instead consumed by behavioural changes elsewhere that leave the bug level unchanged.
Using examples from traffic safety, dangerous sports, and safety equipment, we show how an increase in safety frequently leads to a compensatory increase in risk-taking behaviour.
We demonstrate how this Peltzman Effect applies in software development. We show how improving one area invariably leads to compensatory behaviour elsewhere in the development process, with the net result that quality remains unchanged, even if progress towards the overarching project goal is improved.
We explore the circumstances under which the Peltzman Effect becomes important in software development. We learn when adding quality processes improves quality and when adding them makes no difference.
We also learn how we can reduce the Peltzman Effect, plus how we can improve quality above its present value in an organisation, not by introducing additional quality phases but by shifting the relative importance of quality as a project goal.
Â
