What is the rule of three?
Engineering culture and software practice
The rule of three is a refactoring heuristic: you write something once, wince when you write it a second time, and only extract a shared version on the third occurrence. It is the practical brake on DRY. Credited to Don Roberts and popularised in Martin Fowler's Refactoring as three strikes and you refactor, it is not the same as the separate rule of three about how much harder reusable components are to build.
What this means
The rule of three is advice about timing. The first time you do something, you just do it. The second time, you notice you are repeating yourself but you copy it anyway. The third time, you stop and build the shared version. The point is to wait until you have enough examples to see the real pattern before you commit to a single reusable version.
It has a name because it corrects a very common overreaction. Programmers are taught not to repeat themselves, and the eager reading of that lesson is to unify anything that looks similar the moment it appears twice. The rule of three restrains that reflex, because two examples can look identical by coincidence, and unifying them too early locks in an abstraction that later turns out to be wrong.
There is a second, separate idea that unfortunately shares the name, drawn from research on software reuse: that a truly reusable component is several times harder to build than a single-use one and needs trying in several settings before it is genuinely general. This article leads on the timing heuristic and keeps the reuse-cost idea distinct, because confusing the two muddies both.
Why it matters
For any organisation building or buying software, the rule of three is really a decision rule about when to invest in a shared thing. Building a shared template, a shared process or a shared tool is expensive up front and only pays off if it fits the cases that follow. Do it too early, on the strength of two examples, and you risk a shared thing that nobody quite fits, which then has to be worked around or unpicked.
That cost is easy to underestimate. A shared component carries a coordination burden: every team that depends on it must be consulted when it changes, and a wrong abstraction can be more expensive to live with than the duplication it was meant to remove. The rule of three is a cheap way to avoid paying that price prematurely, by waiting for the third case to reveal what the cases actually have in common.
The idea travels well beyond code. It applies to documents, standard operating procedures and, increasingly, to prompt libraries and AI workflows. If three teams each write their own version of a process, that is often the signal to build one shared version; if only two have, it may be too early to tell what the shared version should even look like. Extracting a shared prompt too soon bakes in an assumption about the task that later cases may not share.
The counterpart worth holding in mind is that some duplication should never be tolerated even once. Where the repeated thing encodes a safety rule, a security control or a legal obligation, the risk of the copies drifting apart outweighs the risk of a premature abstraction, and those should be unified immediately. The rule of three is a default for ordinary duplication, not a licence to scatter critical logic.
How it works
Where the term came from
The refactoring version is credited to Don Roberts and reached a wide audience through Martin Fowler's book Refactoring: Improving the Design of Existing Code, published by Addison-Wesley in 1999 and updated in a second edition in 2018. Fowler presents it as guidance Don Roberts gave him: the first time you do something you just do it, the second time you wince but duplicate anyway, and the third time you refactor. He also gives it the baseball phrasing, three strikes and you refactor.
The reuse version has a different source. Robert Glass, in Facts and Fallacies of Software Engineering, published by Addison-Wesley in 2002, records what he calls the rules of three in reuse as Fact 18: that it is three times as difficult to build reusable components as single-use ones, and that a reusable component should be tried in three different applications before it is general enough to accept into a reuse library. Glass is careful to say the number three is a rule of thumb, not anything magical, and he attributes the underlying idea to earlier work by Ted Biggerstaff, calling it Biggerstaff's Rules of Three. These are two distinct claims that happen to share a name, and this article leads on the refactoring one.
Why three and not two
The reason for three rather than two is close to a geometric intuition. Two points fit any straight line, so two similar pieces of code can share a shape that is pure coincidence, and unifying them forces a pattern that may not exist. The third occurrence is the first that can confirm or deny the shape, because it either fits the emerging pattern or reveals that the earlier match was accidental. Waiting for it means you extract a shared version informed by three real examples rather than a guess based on two.
How it interacts with DRY and the wrong abstraction
The rule of three is best understood as the timing control on DRY, the principle that each piece of knowledge should have a single authoritative representation. DRY says do not scatter the same knowledge across the codebase; the rule of three says do not rush to unify things that only look the same yet. The tension between them is the heart of a long-running argument in the field, often summarised as the wrong abstraction being more expensive than a little duplication. A shared abstraction built too early, on too few examples, can be harder to change than the duplication it replaced, because every caller is now coupled to it. The rule of three is the pragmatic compromise: tolerate duplication briefly, then unify once you can see the pattern clearly.
How experienced teams apply it
Mature teams treat it as a default, not a commandment. They let duplication sit deliberately until a third case arrives, using the discomfort as a signal rather than an emergency. They also know the exceptions: they unify safety, security and legal logic on sight, because divergence there is dangerous, and they do not stretch the rule to justify obvious copy-paste of large, clearly identical blocks. Increasingly they apply the same discipline outside code, resisting the urge to build a shared template, process or prompt until enough real examples exist to show what it should contain.
Examples
Consider a professional services firm whose consultants keep writing client onboarding checklists. After two clients, an eager manager wants to build one master checklist for everyone. A wiser lead waits. By the third client it becomes clear that two of the three share a structure while the first was genuinely different, so the shared checklist is built around the pattern the third case revealed, and it fits the cases that follow rather than forcing a false uniformity.
Picture a charity building a prompt library for its AI assistant. A fundraiser writes a prompt for thank-you letters, then a second, slightly different one for a different campaign. The temptation is to extract a single shared template at once. Holding to the rule of three, the team waits; the third campaign shows that the real shared element is the tone and the donor details, not the structure they had assumed, so the template they eventually build captures the right thing instead of the wrong one.
Imagine a software team of eight that spots the same validation check copied into two services. Because this check enforces a security rule about what input is accepted, the team unifies it immediately rather than waiting for a third occurrence. Here the exception applies: the danger of the copies drifting apart, so that one service quietly stops enforcing the rule, outweighs any risk of a premature abstraction.
Common misunderstandings
People often think the rule of three tells you to allow duplication as a virtue. It does not; it tells you to delay unifying until you have enough examples to unify well. Duplication is still a cost, just a smaller and more reversible one than a wrong abstraction adopted too early.
A frequent confusion is treating the refactoring rule and the reuse rule as the same claim. They are distinct. The refactoring rule, from Fowler and Roberts, is about when to extract shared code. The reuse rule, from Glass and originally Biggerstaff, is about how much harder and more tested a genuinely reusable component must be. They share a number and a name and nothing else.
Some read the rule as a rejection of DRY. It is not a rejection but a brake. DRY says knowledge should live in one authoritative place; the rule of three says do not decide what that place is until the pattern is clear. Unlike a blanket application of DRY, the rule of three explicitly tolerates brief duplication to avoid committing to the wrong shared form.
There is a belief that the number three is precise or magical. It is not. Both Fowler and Glass present three as a memorable rule of thumb. The real content is directional: two examples are usually too few to see a pattern, and three is often enough, but judgement still applies.
Finally, people assume it only applies to code. The same timing logic works for documents, processes and prompts, wherever the choice is between letting several teams do their own thing and building one shared version before you understand what it needs to be.
Risks and boundaries
The clearest boundary is critical duplication. Safety, security and legal logic should be unified the moment it is duplicated, because the harm of the copies diverging is far worse than the harm of an early abstraction. Applying the rule of three woodenly in those cases is a mistake.
The rule can also be abused as an excuse to leave large, obviously identical blocks copied around indefinitely, or stretched to mean never abstract until forced. It is a default for ordinary, small-scale duplication, not a general licence to avoid design. Judgement about the size and importance of the repeated thing still matters.
There is a genuine and unresolved debate in the field about how aggressively to remove duplication. Some experienced practitioners prefer to unify early and inline again if they regret it; others prefer to wait. The rule of three is one well-known position in that debate, not the final word, and the honest framing is that thoughtful engineers still disagree.
What to do next
When a team proposes building a shared template, tool or process, ask how many real examples it is based on. If the answer is two, consider whether waiting for a third would reveal what the shared version should actually contain. If it is three or more, that is often the signal to invest.
Treat a shared component as a coordination cost, not just a saving. Before approving one, ask who will have to be consulted every time it changes, and whether the cases it serves are similar enough to justify binding them together.
Make an explicit exception for anything encoding safety, security or legal obligation. Direct teams to unify that logic immediately, regardless of the rule of three, because divergent copies of critical rules are a serious risk.
Apply the same discipline to prompt libraries and AI workflows. Discourage extracting a shared prompt on the strength of one or two uses, since an early shared prompt can bake in an assumption about the task that later cases do not share, and is then hard to unpick.
FAQs
What is the rule of three in plain terms?
Write something once, tolerate writing it a second time, and only build the shared version on the third occurrence, because by then you can see the real pattern rather than guessing from two examples.
Who came up with it?
The refactoring version is credited to Don Roberts and was popularised in Martin Fowler's book Refactoring. A separate reuse version comes from Robert Glass's Facts and Fallacies of Software Engineering, which traces it to earlier work by Ted Biggerstaff.
Why three and not two?
Two similar pieces can match by coincidence, just as any two points fit a line. The third occurrence is the first that can confirm the pattern is real rather than accidental.
How is it different from DRY?
DRY says each piece of knowledge should have one authoritative home. The rule of three is the brake on applying that too early, tolerating brief duplication until the right shared form is clear.
Are the two rules of three the same thing?
No. One is about when to extract shared code; the other is about how much harder a genuinely reusable component is to build and how many settings it needs testing in. They share only a name and a number.
When should I ignore the rule?
When the duplicated thing encodes a safety, security or legal rule. Unify that immediately, because the danger of the copies drifting apart outweighs the risk of a premature abstraction.
Does it apply outside programming?
Yes. It works for documents, processes and prompts, wherever you are choosing between letting several teams do their own thing and building one shared version before you understand what it needs.
Is three a precise number?
No, it is a memorable rule of thumb. The real lesson is that two examples are usually too few to see a pattern and three is often enough, but judgement still applies.