What are our business rules?
Not too long ago, my typical day would be to review a list of logs that had been submitted by clients. These logs fell into three categories: It was either a BugFix; a new project with feature requests; or a clarification on how the client’s business rules were applied in a given workflow.
One day, the client asked me to provide the business rules for their product. That moment revealed something critical: they had no idea what their own business rules were. The rules had been layered over time by different people making minor tweaks. After 10+ years of product evolution, the logic was opaque. It followed compliance guidelines and passed audits, but there was no central documentation. No single source of truth.
Was it our job to document their business logic? No. But the experience taught me something that’s stuck with me ever since: you need a source of truth for business rules. Simple facts about your business should be logged. Core types should be defined. Every derived rule in an application should trace back to these foundational definitions. A change in one place should cascade predictably.
- Em dash has been placed by me intentionally.