
The Rule of Three (2017) - Torwald
https://andrewbrookins.com/technology/the-rule-of-three/
======
whack
My team inherited a project that was initially built to support US customers.
Because it was successful, it was then expanded to support EU customers as
well. Presumably they loved the rule-of-3 - instead of finding ways to
abstract the existing code to support EU customers, they just duplicated and
forked everything.

Which brings us to today where our team had to maintain 2 different code
bases, doing almost the same thing, in 2 different ways. Every single feature
request we get, takes twice as long, because we have to make them
independently in two different code bases. Similarly for bugs, testing, and
ramp-up time. This is one of the biggest dev complaints that we have even
today, and one of the factors that led to management deciding to "junk it all"
and start over from scratch.

Code duplication is better than the wrong abstraction. And the right
abstraction is better than code duplication. Finding the right abstraction is
very hard, so I can see why people would just settle for the middle ground of
duplicating code. But I still think that trying diligently to find the right
abstractions is what we should be striving for

~~~
ken
> Code duplication is better than the wrong abstraction.

The explanations of this statement that I’ve read make no sense to me. They
amount to “using an abstraction for two things which _just happen_ to be the
same today” is bad. Well, obviously.

It’s like seeing that your tire pressure is 35 psi, and the speed limit is 35
mph, therefore #define speed pressure.

It’s really not difficult to see when A=B by definition or by chance. I no
longer follow the Rule of Three, and I can’t recall any situation where I
thought I’d wasted any time on an abstraction that didn’t end up working. I
have spent a lot of time dealing with duplication when someone copy/pasted a
second case (presumably a follower of the Ro3), even though it was obvious
from the start that the two cases would always be identical.

~~~
earthboundkid
Literally an example from today:

    
    
          updateDescription(image) {
            let description = window.prompt(
              "Update description",
              image.description
            );
            if (description !== null && description !== image.description) {
              actions.doUpdate(image, { description });
            }
          },
          updateCredit(image) {
            let credit = window.prompt("Update credit", image.credit);
            if (credit !== null && credit !== image.credit) {
              actions.doUpdate(image, { credit });
            }
          },
    

I waffled on whether to deduplicate it or let it be. What was the Obvious
Right Choice?

~~~
KajMagnus
> _I waffled on whether to deduplicate it or let it be. What was the Obvious
> Right Choice?_

What about adding a one line comment that this code can be refactored and
improved, and how? But not doing anything immediately.

If you run into this annoying code repeatedly, then, it can be worth taking
the time to refactor it.

~~~
earthboundkid
Hmm, maybe I should wait until there are N examples of the pattern. Maybe 4 >
N > 2 ??? :-D

~~~
KajMagnus
What if N becomes 4 o.O then the weird code will be there forever? :- )

------
ignoramous
This reminds me a different _rule of three_ [0] as described by u/cperciva:

> If you want to compare two things (e.g., "is my new code faster than my old
> code"), a very simple approach is to measure each three times. If the all
> three measurements of X are smaller than all three measurements of Y, you
> have X < Y with 95% confidence.

> This works because the probability of the ordering XXXYYY happening by
> random chance is 1/(6 choose 3) = 1/20 = 5%. It's quite a weak approach --
> you can get more sensitivity if you know something about the measurements
> (e.g., that errors are normally distributed) -- but for a quick-and-dirty
> verification of "this should be a big win" I find that it's very convenient.

[0]
[https://news.ycombinator.com/item?id=18463449](https://news.ycombinator.com/item?id=18463449)

------
dang
Same title, different articles:

2013:
[https://news.ycombinator.com/item?id=6068659](https://news.ycombinator.com/item?id=6068659)

2012:
[https://news.ycombinator.com/item?id=4727023](https://news.ycombinator.com/item?id=4727023)

------
peter303
Refers to how to give a good lecture too- three main takeaways, three
subpoints per main point, three supporting examples per point...

Less than three points sounds too simple; more three points too complicated

------
evelynhayes
Hmm, interesting. I found this fragment to pretty much sum up the article:
"It’s simple: when reusing code, copy it once, and only abstract the third
time. This is the “rule of three.”

~~~
Torwald
He also explains _why_ you should do so.

------
solidist
[https://kentcdodds.com/blog/aha-
programming/](https://kentcdodds.com/blog/aha-programming/)

AHA is the trope of the rule of 3. Albeit this post was written some time
after this post.

I remember it this way: avoid making things dry that they become brittle.

------
mdszy
Article is from 2017.

~~~
dang
Year added above. Thanks!

------
luckyorlame
this post is toxin of the mind. why has it been reposted?

