A few years ago (at BaRuCo 2013) Sandi Metz held a talk about rules.

Afterwards at the party, a conversation ensued where I remember her mention that she put together the rules after years of having clients insisting on them. If I remember correctly she mentioned how she didn’t like formulating rules at all but everyone kept asking for a list until she gave up.

At the time I accepted it as confirmation for my own bias against rules. But I gave up adding caveats and ifs and only-whens to the list of guidelines not long after that.

For years, when presented with rules, alarms would go off in my head and the inner scream of “HOW DARE YOU! YOU DON’T GET TO TELL ME HOW TO DO MY JOB!!!” (three exclamation marks at least) would drown all other thoughts.

A list of rules to follow blindly reeks of oversimplification. I still believe that.

The older I get the more I like “rules” - quotes here because I break rules so often as to render the term non-sensical:

They are a powerful communication medium, catch-phrases that stick to the mind.

The conundrum is that there is no set of rules to apply permanently.

The perennial software developer answer to any question is “it depends” and that is probably the biggest truth in software development today.

It depends on your team, the problem, the tools, the organizational structure and a multitude of other factors.

There are no rules

…but until we learn when to break which one without impacting our goals, a small set of simple to follow guidelines agreed by the team is invaluable as a communication baseline, a teaching medium and an onboarding resource.

There is a code of conduct

If you don’t call them rules, but collaboration guidelines instead, then you are obliged as a well-behaved team member to inform your peers when the guidelines are not followed and to justify your choice.

Sandi’s “you can break the rule if your pair OKs it” is a nice guideline on how to do it.