Main idea

A developer refusing an action creates an error case, and names it. CannotEditInvoicedOrder says "an invoiced order cannot be modified": the whole rule fits in the name, with no comment and no documentation. Nobody wrote that name to document anything — it was the shortest way to designate the refusal at the moment of coding it.

Hence an unexpected seam in the least tidy parts of the code, the ones where no rule is stated in plain terms: the list of error case names. It can be read without knowing how to program, since it is only a matter of reading names.

Three other places produce rules, in decreasing order of return: the checks made at the start of an operation, before anything is modified; the database constraints — what has to be unique, what cannot be left empty; the input validation in the screens.

Why it matters

It opens the reading of rules to those who do not read code, and they — support, pre-sales, product management — are the ones who need the rules. The technical barrier falls on the part of the work everyone thought was the most technical.

It also gives an order of attack when time is short: start with the errors, finish with the screens, rather than going through the files.

Nuances and limits

A badly chosen error name states a false rule with the same confidence as a good one: the source is dense but unverified, and every rule that comes out of it still has to be confirmed.

And the absence of an error case says nothing: a refusal can be expressed in another way, or exist nowhere because the rule is not enforced. An object described with no rules at all signals a superficial description, never a business with no rules.

Open questions

• What do you do with the rules that refuse nothing — those that trigger, compute or complete — since they leave no name behind them?