The golden rule on creating rules

Rules help when they provide a path toward accomplishing a goal that has been proven through successive iterations.

For instance, we use the MVC pattern with most of our web applications because the separation of concerns between data (Model), interface (View), and logic (Controller) generally helps us maintain our software better. It’s proven to be a good approach across dozens of projects. We use a relational database model to store all of our application data because it has generally proven to be a good model for the types of apps we build.

As a company, we regroup at 11:45am each morning for a daily standup meeting. We’ve kept it going — in an almost religious fashion — for the past three years because it gives everyone a quick understanding of what each of our 17 employees is working on right now. And, since we’ve expanded our company across five states, its goals have morphed to not just “who’s doing what?” but “how’s everyone doing?”

Rules start to hurt when we blindly follow them — when they become the reason why we are or are not doing something. When the answer to why we don’t try path X is because path Y is the established rule (or process or policy or law), that rule no longer exists as a vetted way of doing something better. Now, we have a crutch that, at best, we can overcome in spite of its existence, and at worst, sends us spiraling into hours and days of extra, non-essential work to accomplish.

What happens next is the slow death of an organization with once passionate employees. Because, when rules govern the reasons why we do things, the passionate amongst us lose the motivation to figure out a better way. Suddenly, the more appropriate hires are the yes-men (people happily willing to accept processes as doctrine because that is their lot in life), or, even worse, lazy workers (people that gravitate toward work that doesn’t require them to think “outside the box” too much).

This is why, after years of programming and being in business, I’ve followed the one rule that has never changed: Don’t use rules blindly — use them when they actually help solve the problem. There are other ways of stating this, perhaps most simply by Thomas Jefferson. “The hole and the patch should be commensurate.” Use tools to fit the problem rather than trying to stretch the problem to fit the tool. You catch my drift.

In the company, this one golden rule must also apply. Every process must be challengable. A rule that’s worked for five years might slowly catch dust as a corporation grows. And, it is our jobs — as employees and stakeholders — to make sure we do not lazily let the rules dictate how we work. When a process starts feeling icky, it probably is in need of reconsideration. For any small business, one that hasn’t yet morphed into a corporation of bylaws where employees are merely following orders, it is paramount that this be clear: Every process, rule, policy, or bylaw is always up for review.

How do you do this effectively? After all, it’s hard to both constantly try to follow rules while at the same time try to poke holes in them. That’s where culture comes in.

Ideally, rules aren’t often up for review because they are good ones. A corporate culture where everyone’s views are heard, egos are thrown out the door, and everyone shares common goals simply leads to the creation of very good rules to begin with. We can safely progress through our days knowing we’ve created rules with good foundation, so we aren’t always sniffing for those that smell foul.

At the same time, a corporate culture needs to reward progress above anything else. A group that is constantly seeking a better, faster, easier, simpler, or simply more enjoyable means to a goal is a group that will naturally find when a rule isn’t playing well. A culture must allow, with open arms, a bit of experimentation to test out a revision to a rule. So long as the rule whistleblowers are owning change and communicating back to the team that they’ve found a better way, then rules can safely be morphed, iterated, or straight-up removed.

Want to read more by Ka Wai Cheung? Ka Wai’s new book on the modern-day programmer, The Developer’s Code, is available in eBook and print. You can follow him on Twitter @developerscode.