One action, one control, one logic
A fix added a second way to put a file into an order. I made a rule that a second way is a defect, and the agents proved it door by door.
In mid-October a fix added a second way to attach a purchase-order file to an order. Each way worked on its own. Together they made the same action behave differently depending on where the file was dropped, and that is how bugs get in.
My part. I told the agents to explain the whole logic for processing an order once, instead of leaving several ways to do the same thing, because that is where the bugs come from. Then I set the rule: one action, one control, one logic. A second way is a defect.
From a principle to invariants
A principle cannot be tested. Invariants can. The packet listed every door a file could enter by, eight of them, before and after the change, and stated what each door must do.
- People have two doors. Dropping a file on the queue is automatic: the file is read once, when the order's card is created. "Add New Order" is manual: it follows the ERP's own entry order field by field, and a file attached there is kept as a record and never read.
- Email and the mirror of orders typed directly into the ERP are the other two ways a card is created.
- Once a card exists, its file is never read again. The review page and the order page accept no drops at all.
- Two cards are merged only when both name the same customer account. Two dealers are never merged.
- Every header field has exactly one control on the page.
Red first
The tests ran on the old code first and failed exactly where the old code broke the rule: 13 passing and 25 failing on the server's doors. After the change: 39 passing, 0 failing.
A headless browser then walked seven scenes on three role desks. The results were 94 of 94, 94 of 94 and 95 of 95 checks.
Why it lasts
A process rule written as prose drifts as soon as the next feature lands. Written as invariants with a test per door, it holds. The next person or agent who adds a door has to add a test that says what that door does, and the review asks for it.
It also changed how I write packets. When a packet touches a process, it lists the doors before and after, and an inventory taken before building can turn a build item into a decision for me instead.