Software that keeps customer rules in code has a ceiling, and you find the ceiling at the worst possible time. Software that keeps them in a table has no ceiling at all.
Integrates with everything means the connection works
It means the connection works. Connection is the part vendors demonstrate, because connection demos well. Data goes out of one system and arrives in another and everybody nods.
The connection was never the hard part. The hard part is that the receiving system wants the data arranged its own way, on its own schedule, with its own exceptions, and the next customer wants something different.
Multiply that by every customer you have and you have the actual project. Nobody sells you that half.
Four hundred newspapers over modems
In the early 1980s I led a project for National TV Log, and their entire business model depended on solving exactly that.
The idea was clever. Reach into a newspaper’s computer, take the file, insert small boldface advertisements, and put the newspaper back. Fully automated, no humans in the middle.
Around four hundred newspapers, each dialed up over a modem, because modems were what existed. Grab, insert, return, hang up, move to the next one.
Then the part that made it real work. Every newspaper had its own rules about where the advertisements went and how they were formatted. Four hundred customers, four hundred sets of rules, no two the same.
The ceiling arrives without warning
The obvious solution is to handle the differences in code. The first customer is easy. The second is easy. By customer five you have branching logic. By customer forty you have a system nobody can safely change, because every change risks all forty.
The modern version hides behind better words. Per-tenant configuration. Customer-specific business logic. Feature flags. Same problem, and the same teams hardcode the first three customers and discover it at the fortieth.
The rules lived in a table
Outside the code, in a table the program read.
Building that table was not trivial, because no databases existed to put it in. No structured query language, no commercial database engines available to us. We built the table and everything around it ourselves.
With no tools and no prior art, the design was still right. One program, and adding a newspaper meant adding a row rather than writing code. Four hundred was what they happened to have. The design had no number in it at all.
Teams today have databases, configuration frameworks, and rules engines available for free, and a great many of them still put the customer differences in the code.
Three signals the logic needs to come out
A conditional statement that names a customer. The moment code says if this is customer Jones, the rules have leaked into the wrong layer.
A deployment required to onboard a customer. If adding a customer means shipping code, every new customer carries the risk profile of a release.
A change nobody wants to make. When a small adjustment for one customer requires regression testing everybody else, the differences are entangled with the logic.
Doing it at customer five is a morning of work. Doing it at customer forty is a project.
Losing the account to your own success
The code was finished and delivered and the system worked well for them. Then somebody from my team took a job at National TV Log and took the work over. We lost the account.
That outcome is fine, and I mean it. They got a good product and the person who understood it best was now inside their building rather than billing them.
A consultancy that builds something durable and documents it properly will sometimes lose the work to its own success. The alternative is staying indispensable by leaving the thing half explained, which is worse for everyone.
Anyone hiring a consultant should ask what happens when the engagement ends. A good answer describes how the knowledge transfers. A bad answer explains why you will always need them.
The full article is on my site: https://thewritingking.com/rules-belong-outside-the-code/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.