Java Child / State And Change

What Is True Before, And What Is True After

Reasoning about a step in terms of what holds on either side of it turns guesswork into something you can check.

Pick any step in a set of instructions and ask two questions. What must be true for this step to make sense? What is true once it has finished? Answer those in plain language and you have a small contract. The value is not there. The list is arranged. Every item has been counted once. These statements are checkable in a way that a general feeling of correctness is not, and they can be tested against reality rather than merely believed.

This habit turns a long set of instructions into a chain of short claims, and a chain of short claims can be examined link by link. When something goes wrong, you no longer face an undifferentiated wall. You walk the chain, checking each claim as you pass. Somewhere the claim you expected to hold does not, and that boundary is the whole answer. Everything before it is fine and everything after was doomed regardless.

It also sharpens design before anything is built. If you can state clearly what should be true at the end of a chunk of work, you have defined it, and defining it is usually harder and more valuable than constructing it. Beginners commonly begin building before they can say what finished looks like, then discover halfway through that they have two incompatible ideas of the goal. Writing the after statement first forces that disagreement into the open while it is still cheap.