The “Rule of Three”

by Mahesh Pai on September 26, 2008

Fact 18 in Robert Glass’ book Facts and Fallacies of Software Engineering says

There are two “rules of three” in reuse”

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

Glass says that this is just a rule of thumb but I use this rule very often and has served me very well. It applies in all aspects of software development, from engineering to product management. Here are different ways how this rules could apply

  1. You have to apply a generic design at least 3 times before you can be sure it is generic :
  • If you are designing a generic API, verify if the API is adequate by validating against 3 unique consumers of the API. Also no matter how much time you have put in design of an API, you should expect the APIs to change until it has been successfully used in 3 different scenarios.
  • If you are designing an architecture for a Product Line, validate your architecture by applying it to at least 3 products in your product line. You should expect the Architecture to evolve, until it has been used to build 3 different products with it.
  • Validate new UI/features with at least 3 different customers and get feedback before you finalize the solution
  • Validate a new Generic product in 3 Markets before you can be sure that your solution easily scales beyond 1 market
  • Expect a solution to be baked only after it has been improved and adopted across 3 major releases
  1. It costs 3 times as much to build a generic interface than a specific interface
  • Coding a generic API will cost 3 times a much as something specific. Hence before you do decide to be generic, be sure that you indeed need a generic solution. Many times some engineers will try to design generic solutions imagining the possibility of future applications to other scenarios. This can also become into an over engineered solution
  • Not only is it expensive to implement, but it is expensive to test and validate . Testing a generic solution is much more difficult and expensive than testing a specific solution.

Leave a Comment

Previous post:

Next post: