I’m tired of the way if-this-then-that software manages rules.

If you’ve grown beard (and gone a bit bald, like me) administering IfTTT software like firewalls, ETL, mail filters, web crawlers, yahoo-pipes, or just IfTTT; I’m sure you have spent a lot of timecleaning old configuration rules.

When you are part of a team that administers – for example – a firewall, you may end up asking why did someone added that rule in your firewall and why. Of course, you can always disable that rule (that’s the GUI equivalent of commenting out some lines fomr a configuration file) and cross your fingers waiting until a) someone complains or b) you remove the rule after a prudential amount of time.

The problem is that most (if not all) rule-based software doesn’t tell you how much times a disabled rule matches. And that’s a problem.

Before coding the next IfTTT rule-based software consider using three states for your rules:

• State 1: Production – Nothing new here. Just apply the rule.
• State 2: Inactive (log only) – The rule is there; but it’s not alive. When this rule matches, you just increment a counter and and keep searching for the next rule that matches (I wish all routers would have had this feature for years).
• State 3: Disabled (not deleted). Just “commented-out” and kept for reference.

Disclaimer: you can mimic this behaviour in some firewalls combining the allow and log actions, and digging in your logs; but it’s not clear and needs a lot of time for analisys.

This is specially usefull in a machine-to-machine (m2m) scenario. Most rules won’t have a person behind that will complain if there’s something wrong. In M2M the robot in the other side will take some decision based on it (limited) pre-programmed actions and you need to know how many times a rule does apply and if there’s a dumb robot trying to hit a rule you are about to remove.