Thousands of IF/THEN/ELSE rules: code, engine or spreadsheet

Rules that change weekly belong in versioned data with an owner. Rare rules stay as ifs. When a rules engine pays off, and what the finance spreadsheet really costs.

The rule that decides commission usually lives in three places at once, with different values

If a few hundred rules in your company decide pricing, commission, discount and credit limits, start with the boring measurement that settles everything else: how many of those rules changed in the last twelve months, and how many times each one changed.

Rules that change every week belong outside the code, as data, in a table with an owner, a change history and an effective date. Rules that changed twice in five years can stay as an if inside the service, and nobody will suffer for it. A dedicated rules engine covers a third case, rarer than the vendor deck suggests: many rules, frequent changes, a business team that operates them without help, and an auditor asking who changed what. Then there is a fourth place, the most common of all, and nobody chose it. It is the finance spreadsheet, and half of those rules already live there.

A question with 109,620 views and no short answer

In code every rule has an author, a date and a reviewer, plus a two week queue to move half a point

"How can one manage thousands of IF...THEN...ELSE rules?" sits on Software Engineering Stack Exchange with 218 points, 109,620 views and 18 answers. None of them is short, which tells you something. If there were an obvious move, that thread would have died the year it was posted.

The person asking is usually the engineer who opened the pricing file and found eight hundred branches. The person paying asks the same thing in different words: how long does it take to change the partner channel commission, who can do it without waiting on someone else, and what happens to those rules the day the one person who understands them hands in their notice.

Speed, autonomy, key person risk. Those three separate the options better than any technology comparison.

In the code: the best audit trail you own, stuck in the worst queue

A rule in code has the most complete audit trail in your company, and almost nobody notices. Every change carries an author, a date, a reviewer and a diff. You can run git log on the commission file and see when the tier moved, who approved it and what broke the following week. A spreadsheet cannot do that. Most rules engines do half of it.

The price shows up in speed. Moving a tier by half a point costs a ticket, a prioritization queue, a review and a deploy. On a team with slack, two or three days. On a team running three fronts at once, two weeks, and that is precisely when somebody in finance opens Excel.

There is a quieter cost, and it is the one we keep meeting on systems inherited after a vendor walked away: the rules are in the code and nobody can explain why they are the way they are. The if has been there since 2019, with a magic number, no comment, and the customer who asked for that exception left the company. Code is an excellent record of what was done and a poor record of why. That gap has a schedule and a revenue price tag, and it belongs in the same risk register as the rest of your engineering backlog. If you are weighing who should own that work, the managed squad versus staff augmentation decision usually turns on exactly this kind of knowledge, not on headcount.

I have been on the buying side of that table. In an equipment rental startup I founded, I hired developers without being able to judge what they told me. I would ask for a change to a pricing rule, hear an estimate, write it down, and have no way to argue with the number. The sprint ended without the delivery, and I blamed the team. The missing question was simpler than I thought.

In a rules engine: you take the rule out of the deploy and buy an operation

When the system computes 12% and the sheet pays 12.5%, the conversation stops being about technology

The promise is honest: take the rule out of the release cycle and let the business change it. Drools, decision tables, DMN, a flag service with conditions. Mature options, serious teams using them.

The line that rarely appears in the deck is operations. A rule written in the engine is still code, living in an environment that usually lacks everything that surrounds code: automated tests for the rule, a staging environment, review by a second person, a one command rollback. When the wrong rule goes live at three in the afternoon on a Wednesday, you find out from the next day's reconciliation.

Performance is the other half, invisible while volume is small. Chained evaluation that flies in the demo starts to drag once the base grows and every order fires hundreds of checks. I wrote about that exact surprise, and the script barely changes from one company to the next.

And there is the irony about key person risk. Before the engine, one person knew the rules. After it, one person knows the rules and the engine.

When it genuinely pays off: hundreds of rules, changes at least monthly, a business function that operates them for real (credit, insurance, tax, dynamic pricing), and a formal audit requirement. If three of those four are not true where you work, you will pay for the rollout and keep filing tickets to change a percentage.

In the spreadsheet: five minutes to change, zero lines of log

The spreadsheet wins on the two criteria that matter to the person who needs the change: five minutes, and no permission to ask for. That is why banning it never works. It is usually born on a Friday close, when the system number does not match and somebody has to pay commission on Monday.

The bill arrives later. No record of who edited the cell, no test, and the source of truth splits in two. The system computes 12% and the sheet computes 12.5%. Invoices come out of the system, commissions get paid from the sheet, and nobody notices for four or five months. When someone finally does, the argument is not about software. It is about back paying thirty sales reps.

Worth separating two things that get treated as one. The modeling sheet, used to sketch scenarios before a decision, is useful and should stay. The sheet that decides money actually paid is a production system with no log, no formal owner and no backup, running on one person's laptop.

"So we just move everything into a table"

No, and the reason is dull. Parameters fit in a table: percentages, tiers, caps, waiting periods, eligible regions. Pulling those out of code is cheap and solves most of the real problem, because most business requests are a number change.

Chaining does not fit. When the rule reads "8% off above 50 units, except for distributors, who get 5%, unless the contract predates 2023", you try to express that in columns and end up writing a homemade interpreter inside your own product. At that point you have built a rules engine with no debugger, no tests and nobody who understands it besides its author.

The cut I use is crude and it holds: numbers go to a table with an owner and an effective date, chained conditions stay in code with a test whose name spells out the business case in plain English. I cannot tell you where that line sits for a company with two engineers and twenty rules. At that size there is probably no problem to solve yet.

Four questions that place each rule

Take the ten rules that touch money in your company and answer, for each one:

1. How many times did it change in the last twelve months? Zero or one points to code, monthly or more points to data with an effective date.
2. Who asks for the change and who can execute it unaided? When both answers are the same function, that rule can live outside the deploy cycle.
3. What does three days of it being wrong cost? A wrong commission for three days is embarrassing, wrong interest for three days is a letter from a lawyer.
4. If the person who explains that rule resigns on a Friday, who answers on Monday? With no name on that line, where the rule lives is the smallest of your problems.

The fourth is the cheapest to answer and the one that stings. It also explains what senior domain knowledge costs, and the current rate bands are here. If nobody in house can carry the work, an embedded squad is one way to buy the answer, though the diagnosis comes first either way.

The column that decides money your system knows nothing about

Open the spreadsheet finance uses to close the month and look for the columns holding formulas rather than pasted values. Every one of those formulas is a business rule your company runs monthly, untested, unversioned, unowned.

Count them. Then ask your team how many of those same rules also exist in the code, with a different value. The distance between those two numbers is the size of the actual work, and it is almost always smaller than the rewrite somebody will propose in the next meeting.