At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this:
The first time you implement something, just do it.
The second time you implement the same thing, copy it.
The third time, refactor.
The OP seems like an interesting variation on the same theme.
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.
> 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.
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?"
Awesome. Where did you hear this? A Google search for "Everything sucks until version" returns no results.
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.
I think it's from Jeff Atwood, but I can't find the exact source. It is also rather true for Samsung Galaxy and iPhones. First memorable Windows "for everyone" is 3.1 and the list goes on and on.
Huh, that was the exact rule I adopted the first time I had to work on a "real" project. I wonder if I'd previously read it into my subconscious, or if it's simply kind of obvious. :)
This is even more true in game development. So many developers making games want to try and make reusable components across games but almost every game is "special" and will require some kind of tweaking to make the component truly reusable.
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.
I have a problem with the word reusable. A reusable software should be a component in a larger solution. Not a complete solution itself.
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.
Of course a piece of software that you intend to distribute to others must be reusable - that's the whole point. However, there are plenty of software systems that are one-offs. In the case of Stack Overflow, they wanted to see if the overall solution (which is much more than just the underlying code) would be good for different types of users or whether they had built a one-off.
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.
Codinghorror is the personal blog of the founder of Stack Exchange. He left that company and later founded Discourse. Why wouldn't he talk about the things he's built and working on on his blog?
I know, I know who he is. It's just I am not convinced at all that the examples used are the best (or even good for that matter) in the field of code reuse etc. He's clearly just advertising his products which can be done in more honest ways.
I don't understand this at all. This is a personal blog. That means that the people who read it do so for no other reason than that he's interested in what he has to say. A blog is a platform to say whatever you want to say. If that's thinly veiled advertising, then so what? What you consider advertising someone else with a different background might consider insightful. I don't understand the dishonesty charge. There's nothing he's 'supposed' to be doing with it. So how could someone say he's pretending it's something it's not?
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.
I remember that a Xorg development guideline explicitly required the same code to be used by at least two different subsystems (using hard coded if-based paths or copy/pasted) before it could be generalized into a parametric reusable function.
Nice post. I was more interested in the fact that Discourse was being real-world tested/developed with three clients than this trite "rule of three" business though.
I have had a similar thought. The multiple of 3 seems to be a nice heuristic to track and tame complexity in many fields. Nature of any problem undergoes fundamental changes when the problem size is tripled and our solutions should be reviewed accordingly.
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.
I like the sentiment. Battle testing your generalised solution is always a good idea. It's also a good idea to know when you don't need a generalised solution.
[0] http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...