[babuskov]

This is similar to Jeff's rule "b". The only difference is cause and effect ordering. Jeff suggests you build it, reuse it, and when you reused it thrice in different applications, than call it a general purpose library.

It seems to me that Jeff misunderstood what rule of three means, or he's just trying to re-tell the Wikipedia article in his own words.

The "Rule of three" you quoted is how it should be done. Create, copy/paste, refactor to be reusable. And there's nothing wrong with that.

[brazzy]

> It seems to me that Jeff misunderstood what rule of three means, or he's just trying to re-tell the Wikipedia article in his own words.

Not at all - he's actually making a much deeper point: that something cannot really claim to be reusable until it has actually been used in three different places.

Because if you writer a reusable component for just one product, chances are very high that even if it's technically reusable, it will end up conceptually coupled to that one product too much to actually be useful elsewhere.

[Cogito]

To be fair to Jeff, he was quoting from "Facts and Fallacies of Software Engineering" by Robert Glass [0].

The two rules are very similar, and that's why I think they have the same 'theme'. In one we are talking about when to refactor and in the other when to create a library, but both are essentially the same idea. Don't spend time generalising something that might never be used again. Three existing uses is (apparently) a good heuristic for answering "When is something going to be reused lots?"

[0] http://www.amazon.com/exec/obidos/ASIN/0321117425/