The last two practices start to enter the craft of programming. So while it's easy to see their benefit, they're much harder to demonstrate the first of which is the role of three. This is about deferring decisions until necessary. As programmers, we have a tendency to make premature optimizations to the code. We believe we know how the code will be used in the future, so we go ahead and write it that way, but maybe that code wasn't needed.

so we go ahead and write it that way, but maybe that code wasn't needed. It's hard to say it's already written, so that's the way it was used. Also, many programmers don't stick around in a code base long enough to see it evolve. The rule of three challenges us to wait until the third, or really even fourth time we encounter the same piece of code before we make a decision about how it changes. Again, it's difficult to demonstrate the

of code before we make a decision about how it changes. Again, it's difficult to demonstrate the power of this practice. It would require us reviewing code decisions over the course of time, effectively seeing a time lapse of code changes and comparing that to a parallel code base that was practicing the rule of three. That's nearly impossible. What I can demonstrate is how we become better at predicting the future.

What I can demonstrate is how we become better at predicting the future as we have more data. Let's consider a number sequence. If I provide the first number in the sequence and ask what's next, many of us might guess four or eight, maybe three, but it could also be a decimal series of 2.1 or a descending series of one. The reality is we don't really know.

or a descending series of one. The reality is we don't really know. If I provide the second number of the sequence and ask what's next, we may dial in our guesses a little more. In this case, six or eight, maybe some of us might guess 16. While there may be more agreement, there's still a lot of options. When I provide the third number of the sequence, our guesses become much more accurate.

When I provide the third number of the sequence, our guesses become much more accurate. We might recognize this as an exponential series, or more specifically where the next number is the previous number squared. And while we might have to break out our calculators, many of us would say with confidence, the next number is 256, and that demonstrates the rule of three. It wasn't until we had three data points that we were accurately able to predict.

It wasn't until we had three data points that we were accurately able to predict. The fourth, bringing it back to code, the rule of three challenges. Other practices, we may learn early on in programming, such as not to repeat yourself or DRY as programmers, we're taught not to live with duplication. Anytime we encounter duplication, we think we need to abstract that, but the rule of three shows us that

Anytime we encounter duplication, we think we need to abstract that, but the rule of three shows us that that might be too early. Sandy Metz is quoted as saying duplication is far cheaper than the wrong abstraction. If we take a hard look at our programming history, the truth is we force architecture and design patterns too early. The rule of three challenges us to slow down, live

and design patterns too early. The rule of three challenges us to slow down, live with a little bit of duplication, write a little extra code, allow things to evolve naturally. If you do, you'll become much more accurate at predicting the future, allowing you to make better architectural decisions and apply the right design patterns.