In Fieri, Non Ex Post Facto

I keep hearing people (often experts) say things like, “the system clearly wasn’t tested thoroughly” whenever they discuss some (in)famous incident.

Testing a system thoroughly sounds fine in theory, but what does it actually mean? Especially after development, knowing when testing is “enough” is a tricky question, and incidents will still happen.

As W. Edwards Deming famously said, “Quality inspection is too late.” By the time we inspect, the system is already built, and the cost of fixing issues is far higher.

That’s why building quality in from the start, with short, continuous feedback loops, is so crucial in software.

Unlike many other artefacts, software evolves rapidly. Our confidence in it doesn’t come from hoping testing catches everything, but from understanding and shaping its behaviour over time.

Quality starts by defining behaviours clearly, grows by keeping focus on those behaviours rather than their implementations, and is sustained by maintaining those behaviours consistently.

The reality is, we can change a system easily when we understand how it behaves, not just how it’s built. Focusing on behaviour rather than implementation is what makes testing and feedback a real tool for reliable, adaptable systems.

This is why I insist so much on practices centred on behaviours and short feedback loops: test-driven development/ATDD and continuous integration/trunk-based development, enclosed in a frame where quality is continuously inspected by multiple eyes through social programming practices.

So rather than fixating on testing thoroughly at the end, let’s focus on adopting high-quality iterative and incremental processes that are designed to spot problems early and bake quality in from the very beginning.

In fieri, non ex post facto.

Originally posted on LinkedIn.