Rules and Conventions

 

A convention is a generally followed practice.  It's a loosely adhered to social norm or value.  A rule, or law is a regulation or guideline that is enforced.  There are consequences for breaking it.  Penal codes are good examples of laws while the Ten Commandments, conventions.

We see rules and conventions throughout both human processes and in code.

 In Process

An example of a convention is the act of returning your shopping cart at the grocery store parking lot.  It's good manners.  Since most people follow this convention, shoppers are able to quickly get a cart when they enter the store.

 

A similar process that's instead enforced as a rule is the coin operated locker.  To get a locker, you insert a deposit.  This frees up the key to let you lock the locker.  When you're done, you unlock the locker and your deposit is returned.  This resembles the shopping cart system but has stronger enforcement.

In Code

Style guides are one example of conventions a developer is encouraged to follow in code.  They're also often a subject of much contention (We'll return to this later).  If someone fails to conform to the convention the application will still run.

Syntactic grammar, enforced referential integrity, data typing, etc are all examples of rules.  If code doesn't meet these rules, it won't work.  If a value isn't of the right type, it cannot be assigned.

Pros and Cons

A law is a more reliable policy.  It has low or no risk of being broken.  As such it can reduce complexity and add efficiency.  However, it may add overhead due to the necessity of an enforcement mechanism.

Intuitively one may notice that laws are well suited to critically important matters.  There's a cost/benefit trade off.  When the cost of enforcement is less than or equal than the cost of violation, a rule makes sense.

A convention carries a higher likelihood of violation but lacks the overhead cost of enforcement.  However, conventions need a reliable communication mechanism in place in order to function.  A cryptic or orphaned convention can cause big problems and can be unfair.  Imagine like in the Mel Brooks skit, if there was a lost commandment, "Thou Shalt XYZ."  We'd all wind up in Hell without knowing why.

 

Since conventions aren't actively enforced, they tend to work best when they align with the natural incentives of their targets.  

Aligning Incentives

The shopping cart convention works because it helps shoppers shop.  Poorly designed conventions however, fail to align incentives.

The classic case is the eternal battle over the toilet seat.  Women prefer the toilet seat down so that they don't accidentally land in toilet water when using the bathroom in the dark.  Men prefer the seat up so they don't risk an accident when they're in a hurry to go.  Women get the worse end of the deal so they're naturally the ones who champion the convention of putting the seat down.  While the considerate man will adhere, it goes against his own interests.  At times he may forget or actively choose to leave the seat up.

The ageless conflict around the toilet seat is a tell tale sign of a convention with misaligned incentives.  In code, we often see this with style guidelines.  Developers incentives are to produce high quality features as quickly as possible.  At first, style guidelines appear only to slow them down.  Over time, they may be internalized and in fact speed up the whole team.  However upon adoption they are usually met with "weeping and gnashing of teeth."

Convention Over Configuration

Ruby on Rails adheres to the principle, "Convention Over Configuration."  The framework enables the developer to "only specify unconventional aspects of the application."  This speeds up development, matching the incentives of its user.

"A software framework based on convention over configuration often involves a domain-specific language with a limited set of constructs or an inversion of control in which the developer can only affect behavior using a limited set of hooks, both of which can make implementing behaviors not easily expressed by the provided conventions more difficult than when using a software library that does not try to decrease the number of decisions developers have to make or require inversion of control."-- Wikipedia

I personally find this a great summation of the approach and trade-offs of "Low Code Solutions."  One could in fact make the argument that Rails itself IS a Low Code framework.

Best Practices

Until someone invents a rule-toilet where you deposit your pants, my advice is to follow the convention and put the seat down.  Generally speaking though, if setting up a new convention, take time to consider the incentives and how to align them.  Conventions can be ignored or gamed.  They can cause unnecessary conflict.  They need to be clearly communicated.  Consider these intangible costs when deciding to use a convention.

As far as rules go, they're best used when they pass the cost-benefit trade off.  In particular, one should almost always take advantage of rules if the enforcement mechanism is already in place or has no cost.  In code, the cost of rules is low and the benefit is high.  The default tendency should be towards rules over conventions.