Practice
Decision tables beat nested ifs, and it is not about elegance.
The argument for tables is usually made on readability. The stronger argument is that a table shows you the rows you forgot.
The same policy, two shapes
Take a policy with three inputs: a score band, a customer segment, and a channel. In conditional form it becomes a tree — check the segment, then within that check the band, then within that check the channel. The tree is fine when you write it. The problem arrives on the fourth edit, when a branch needs an exception and the natural move is to nest one level deeper.
As a table, the same policy is a grid. Each row is one combination of the three inputs and the outcome for it. Nothing is nested, so nothing gets deeper. Adding an exception adds a row.
The real advantage: absence is visible
A conditional tree does not tell you what it does not cover. A missing branch looks exactly like a branch that is intentionally absent — the code falls through to whatever the default is, silently, and you find out when a customer lands in it.
A table has a shape. If your three inputs have four, three and two possible values, there are twenty-four combinations, and you can see how many rows you have. The gap between twenty-four and the number of rows you wrote is the number of cases you have not thought about. That is a question the code shape asks you, unprompted, every time you open it.
A nested conditional hides its gaps. A table counts them for you.
Who can review it
Policy is agreed by people who do not write code — a credit committee, a fraud lead, a compliance officer. When the policy is a tree of conditionals, review happens by translation: an engineer explains what the code does, and the reviewer approves the explanation rather than the artifact.
That gap is where most policy defects are born. Not in the logic, which is usually simple, but in the handoff between what was agreed and what was implemented. A table closes it, because the thing the committee signs off and the thing that executes are the same object.
When a table is the wrong shape
Tables are for combinations of discrete inputs. They stop helping in three cases, and forcing them is worse than nesting.
- Continuous maths
- An affordability calculation or a ratio is arithmetic, not a lookup. Compute it first, then band the result and let the table read the band.
- Genuinely sequential logic
- When step two only makes sense given the outcome of step one, that is a flow with branches, not a grid. Model it as a branch and keep tables inside the branches.
- One input, many thresholds
- A single-axis cut-off is a rule. A table with one column is a table pretending it has a reason to exist.
How this looks in a flow
In practice the shapes compose. In ArboRule a Code node derives the ratios, a Scorecard turns characteristics into points, a Decision Table maps score band, segment and channel to an outcome, and a 2D Matrix handles the two-axis grids like limit by score and income. A Rule node carries the single-condition hard stops that do not deserve a grid.
That composition matters more than any individual shape. The failure mode is not choosing a table over a conditional — it is having one artifact that mixes derivation, scoring and policy, so that changing a cut-off means reading arithmetic to find it.
Questions
Are decision tables slower than if-statements?
Not meaningfully. A table lookup is a small, bounded operation, and in any real decision the time is dominated by the external calls — a bureau pull, a device check, a database read — not by the branch evaluation. Choosing the shape on performance grounds is optimising the part that was never the cost.
How many rows is too many for one table?
The count matters less than whether the rows share one question. A table with two hundred rows that all map the same three inputs to an outcome is fine and readable. A table with twenty rows where some decide eligibility and others assign a price is already two tables, and it will get harder every time either policy changes.
Should every rule become a table?
No. A single condition is a rule and reads better as one. Tables earn their place when several discrete inputs combine, because that is when the number of possible combinations exceeds what a person can hold in their head while reading a nested conditional.