[hcarvalhoalves]

The problem I’ve seen with the “rule of 3” in real life is that by the time someone is writing a similar implementation by the third time, 5 years have passed and the entire team has rotated, so the programmer doesn’t have enough context to DRY anymore, and then the failed “big refactor that breaks corner cases” happens.

I find a mentality of _striving_ for DRY by default — even if end up choosing to duplicate for pragmatic reasons — to be beneficial in keeping programmers looking around for opportunities and refining the understanding of the context, with a better chance of incremental progress.

[Jtsummers]

That's not a problem with "rule of 3", it's a more general problem: Misunderstanding these "rules" and "principles". Specifically, trying to treat them as absolutes. "We must repeat ourselves three times to comply with 'rule of three'." Well, no, that's silly. It's a heuristic, a guideline, not a law that can never be broken. If you spot a clear case of real duplication even before creating the duplication (easier with experience, either total or with the system under development), then you can clean it up earlier. If you can't see the duplication or are uncertain about the duplication ("Is this real duplication, or just coincidence? Am I going to change 90% of the code after all the modifications are done or just one value which could become a parameter?"), then go ahead and repeat yourself.

The same issue arises with YAGNI. People often jump too quickly to shouting YAGNI when the reality may be, and again this comes from experience-enabled judgment, that you are going to need it. "Don't make it a parameter, we aren't using it yet and don't know that we will." "But we do know, it's in the customer requirements that we don't hardcode the database server name everywhere, also it's just sensible."

These rules, principles, guidelines, laws, or whatever term gets assigned to them are there to help. They are not there to be excuses to stop thinking, but to provide a structure around thinking and a way to discuss with other people. But that structure is not absolute, experience and judgement can lead to breaking any of these rules at any time based on the present situation. That present situation that only you (and your team) know, but not the people who discovered, created, or coined the rules. They can only offer advice and guidance and not absolute instruction.