Monday, May 21, 2012

Convention and Enforcement

One of my clients is in the midst of a major architectural consideration: do they enforce rules, or govern by convention? The system as it's currently built uses convention; there is pretty much no enforcement or validation of business rules. Instead, it focuses on allowing flexibility and allowing the user to determine business rules. The problem is that the dev team spends a lot of time chasing problems that turn out to be bad or unexpected data.

Hence, the discussion. It goes something like this:
"We're having problems where data doesn't conform to our assumptions, and we're spending time tracking them down. We should enforce the rules we're assuming."
"The rules might change, and our system needs to be flexible to accommodate it. Any rule we're assuming should be considered a bug."
"Some rules won't change - we know, for example, that a widget will belong to exactly one frobble. We can enforce those rules."

And so on.

There's not really a best practice here; some systems will fall closer to the enforcement end of the spectrum, and some closer to the convention end of the spectrum. The thing to consider is this: "Who knows the rules? The creators of the system or the users of the system?" Choosing to enforce rules lessens the chance that a user is going to get themselves in trouble, but will give them less freedom to make business rule changes. Choosing convention puts the onus of rule creation and enforcement on the user of the system. Choosing convention also means that you can't make internal assumptions and then expect people to conform to them - after all, they don't know the internal implementation details. Choosing enforcement means that you have to change the system every time the business rules change.

Hours of log diving have made me lean toward enforcement of rules where we know them, but systems that use convention to enforce rules can work. Just make sure it's an explicit choice.

No comments:

Post a Comment