The first time you implement something, just do it.
The second time you implement the same thing, copy it.
The third time, refactor.
[0] http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...
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.
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.
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?"
I think there might be some truth to this. My first MVP sucked hard. My second version of it was passable, but still left quite a bit to be desired. I have a feeling whenever I ever get to version 3, it will be good.
And then, you've just bloated your component to support different use cases and made it slower, harder to understand, and potentially buggy; all in the name of "reusability". And it takes you 3 times longer to implement this shared component vs just making copy & paste single use solution.
Game development is truly an art. Knowing when to just "get it done" vs "write a more reusable component" is something that I've seen very few people in game development be able to get right.
If I accept that Stack Overflow or Discourse are reusable, because you can run them on different urls with different graphics, topic, moderators and users, then every application, for example Photoshop, is reusable in the same way, because multiple people use it to perform multiple tasks with images.
What you do with Discourse is good engineering, but there is nothing special about it. Every serious CMS, like WordPress or Drupal must inevitably be usable more than once.
With Discourse they are setting out from the beginning to make a reusable piece of software but that doesn't mean they are guaranteed to do so. Hence the extended development time before they offer it more widely.
Example: DHH built Basecamp and pulled Rails out of it. He (and now many others) used Rails to create web apps.
Less than three? Control-C, Control-V.
Three or more? Refactor!And I don't fault the authors, because of course they want their creations widely known. But it isn't generally conceived as "I have this great epiphany and I must share it", but rather "I need to get some product pimping out, so what should I write about?" I've done it enough times myself.
Here is what I mean. Say your startup has only one employee. You come up with certain processes to make it productive. However, when the team size goes to 3, 9, 27, it would be a good idea to review those processes and rules. Those seem like appropriate milestones to me for future planning. Not too short, nor too long.
Another example: Let's say I want to understand a topic like, say, Relativity. I think an effective approach would be to first read a one paragraph summary which barely describes the big picture of it. Once I've done that, I look for an article 3-times as long (say, a page). Next would be an essay which is about 3 pages. 9 pages, 27 pages and so on.
By not taking a big jump, (say a multiple of 10 or more), I make sure that I have a good foundation based on experience to be able to understand the next stage of complexity. And a jump less than a multiple of 3 would tend to be not the most productive.