
The Rule of Three - mschalle
http://www.codinghorror.com/blog/2013/07/rule-of-three.html
======
Cogito
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.

[0]
[http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...](http://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

~~~
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.

------
socialist_coder
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.

------
vlasta2
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.

~~~
aptwebapps
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.

------
one-man-bucket

      Less than three? Control-C, Control-V.
    
      Three or more? Refactor!

------
lysa
Wow what a horrible way to advertise your products. Disguise your
advertisements into some substanceless article seemingly useful.

~~~
vinceguidry
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?

~~~
lysa
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.

~~~
vinceguidry
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?

------
gioele
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.

------
mafro
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.

------
nileshtrivedi
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.

------
quchen
What _hyphenated site_ is he referring to?

~~~
klimeryk
Experts Exchange ([http://www.experts-exchange.com/](http://www.experts-
exchange.com/)) probably.

~~~
ShardPhoenix
The joke being that before they switched to the hyphenated url, it could be
read as expert _sex_ change.com

------
groundCode
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.

