Post-Apocalyptic [or bad] software is hard to modify because it doesn’t behave in predictable ways, instead you only have beliefs about how it works. […] It’s hard to write software based on beliefs, because they’re often wrong, so you end up having to empirically verify your solution, step by step. [Or you keep using beliefs, which leads to unreasonable software.]

We make unreasonable software reasonable by turning each belief into either a behavior or a property. Behaviors are aspects of software that can be validated empircally against an environment. Properties are aspects of software that can be validated statically or through local exercise.

lethain.com

Reclaim Unreasonable Software.

Source

Behaviors and properties can be either observed or tracked (via reporting) or verified (before releasing the software).

You get the best results by evolving beliefs into asserted properties, followed by verified behaviors, but there is a surprising amount of value in just moving them into tracked behaviors or properties. It helps you understand the level of effort that’ll be required before you can begin reasoning about your software again.