5 ms·

The Rule of Three (2017)

51 points by Torwald 7y ago

mdszy 7y ago
Article is from 2017.
- dang 7y ago
  Year added above. Thanks!
evelynhayes 7y ago
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 7y ago
  He also explains why you should do so.
whack 7y ago
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
- majormajor 7y ago
  I completely agree with your last paragraph, but you (or your management) lost me with the second: "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." Starting over from scratch doesn't seem like it's going to help find the right abstraction[0]. All the nasty edge cases and such that make the existing code ugly are what you need to consider in order to know the "right abstraction", and they're usually what get ignored in the early design stages of a new rewrite. You're at the point where you've learned pretty well what aspects are both shared and stable between the systems. Seems like a perfect opportunity to start to modularize the existing codebases instead - start to split out the shared functionality so it only has to change in one central place, while allowing the two different top-level projects to have their specific quirks on top of that. [0]for most business processes, I think "finding the right abstraction" is actually a dangerous red-herring. Sometimes you have complicated processes. Sometimes clean readable well-organized code is what you need, not an abstraction over it.
  - whack 7y ago
    I mostly agree with you. I wouldn't recommend doing the rewrite for this reason alone. There were other reasons involved in doing a rewrite. The pain of maintaining a duplicated code-base was only one of many pain points in the status quo.
- Bokanovsky 7y ago
  I've been involved in projects that take it a step further. They realise that two products or code bases are similar enough that they can be duplicated, like the example you've given above. But instead of splitting the code bases, they decide to have one code base, that codegens the code for both projects. At first code gen this way seems ideal, but the trouble is you'll start to realise one project needs a feature that the other doesn't and or it needs something implemented in a different way. The code gen in question doesn't support feature flags in a straight forward way, and adding extra features comes at a cost greater than just writing code to do it properly. Then you'll have to start maintaining not only the two projects, but a proprietary codegen framework.
deleted 7y ago
[deleted]
ignoramous 7y ago
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 7y ago
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
solidist 7y ago
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.
luckyorlame 7y ago
this post is toxin of the mind. why has it been reposted?
peter303 7y ago
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

51 points by Torwald 7y ago

mdszy 7y ago

Article is from 2017.

dang 7y ago
Year added above. Thanks!

evelynhayes 7y ago

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 7y ago
He also explains why you should do so.

whack 7y ago

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

majormajor 7y ago
I completely agree with your last paragraph, but you (or your management) lost me with the second: "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." Starting over from scratch doesn't seem like it's going to help find the right abstraction[0]. All the nasty edge cases and such that make the existing code ugly are what you need to consider in order to know the "right abstraction", and they're usually what get ignored in the early design stages of a new rewrite. You're at the point where you've learned pretty well what aspects are both shared and stable between the systems. Seems like a perfect opportunity to start to modularize the existing codebases instead - start to split out the shared functionality so it only has to change in one central place, while allowing the two different top-level projects to have their specific quirks on top of that. [0]for most business processes, I think "finding the right abstraction" is actually a dangerous red-herring. Sometimes you have complicated processes. Sometimes clean readable well-organized code is what you need, not an abstraction over it.
- whack 7y ago
  I mostly agree with you. I wouldn't recommend doing the rewrite for this reason alone. There were other reasons involved in doing a rewrite. The pain of maintaining a duplicated code-base was only one of many pain points in the status quo.
Bokanovsky 7y ago
I've been involved in projects that take it a step further. They realise that two products or code bases are similar enough that they can be duplicated, like the example you've given above. But instead of splitting the code bases, they decide to have one code base, that codegens the code for both projects. At first code gen this way seems ideal, but the trouble is you'll start to realise one project needs a feature that the other doesn't and or it needs something implemented in a different way. The code gen in question doesn't support feature flags in a straight forward way, and adding extra features comes at a cost greater than just writing code to do it properly. Then you'll have to start maintaining not only the two projects, but a proprietary codegen framework.

deleted 7y ago

[deleted]

ignoramous 7y ago

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 7y ago

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

solidist 7y ago

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.

luckyorlame 7y ago

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

peter303 7y ago

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