The Rule of Three

Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalised, most flexible, most one-size-fits all solution that has ever been conceived. We think we’ve built software that is a general purpose solution to some set of problems, but we are almost always wrong. We have the delusion of reuse. Don’t feel bad. It’s an endemic disease among software developers. An occupational hazard, really.

If I have learned anything in my programming career, it is this: building reusable software, truly reusable software, is an incredibly hard problem – right up there with naming things and cache invalidation.

There are two “rules of three” in [software] reuse:

  • It is three times as difficult to build reusable components as single use components, and
  • a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Yes, this is merely a craftsman’s rule of thumb, but the Rule of Three is an incredibly powerful and effective rule of thumb that I have come to believe deeply in. It’s similar to the admonition to have at least one other person review your code, another rule of thumb that is proven to work. To build something truly reusable, you must convince three different audiences to use it thoroughly first.

OK, so you built a solution that scratches your itch … but does anyone else care? How many other people have the problem that your software or website addresses? How many other competing solutions are there to choose from? Outside of your personal patient zero case, can you convince anyone to willingly, or even enthusiastically, adopt your solution? That’s your first hurdle. Can you even get to number one?

So the next time you think “I’ve built a reusable thing!“, stop, and think “how can I find three users, customers, or audiences, to prove that I’ve built something reusable?” instead.