In general, only on the third time of encountering a common behavior should you refactor components to share a common abstraction of that behavior.

Clarification: The abstraction could be an abstract class or interface depending on the use case and language.

I've generally used this principle when I'm programming, but have never seen it formalized anywhere. I was working with a friend on his project and I mentioned it to him, and he thought it was valid enough to be codified somewhere on the interwebs (so here it is - thanks Sri!).

General Explanation

If you are building an application and find yourself writing a component that shares similar (but not exact) behavior with another component, we general think there's a need for a common abstraction. I contend, this should not be the case when only two components share that behavior (unless that behavior is sufficiently complex and it makes sense for both components to share some sort of type hierarchy). By creating an abstraction, you may be introducing unnecessary complexity into code or force components into unnatural/unnecessary type hierarchies.

Upon the need of the same behavior by a third component, only then should you take steps to implement the abstraction. It stands to reason that if the behavior is needed a third time, it will probably be needed a fourth or fifth as well. This is not always the case on the second time (it's a gamble).

Supporting Evidence

An argument supporting this principle was provided by a friend of mine, John Ruiz, who notes the underlying lesson in Fred Brooks Second System essay [1]. The idea is that your second implementation will be "elephantine, feature-laden monstrosities"because of "inflated expectations" [2]. In our case, the inflated expectations come from you guessing at the scope of the abstraction base on what you think you will need for future use cases (with only two use cases to guide this decision). This is a general "code smell" indicating over-engineering.

Works Cited

[1] The Mythical Man-Month. http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959
[2] Second-system Effect. http://en.wikipedia.org/wiki/Second-system_effect