The Baseball Rule

Very often, in a course of the engineering life, whether it is a process or code, repetition happens. I suggest a simple rule to decide what to do.

TL;DR  

I have been using a simple heuristic to deal with slowly emerging patterns.
At 3 occurrences , I pause and review the context and approach.

Hence the name “Baseball rule”, a reference to the “3 strikes and you’re out” rule. (One of the very few things I know about Baseball).

Benefits  

• delays the introduction of complexity in the system.
• brings the attention to slowly changing circumstances
• creates an opportunity for relevant architecture discussions

More Details  

Deciding not to do anything at this point is a valid outcome. Those 2, 3 occurrences could be all there is. Or the change could be slow and an investment now would only be amortized far in the future.

Example applied to code  

1. A bit of business logic gets written.

if price < 2000:
  tax = price * 0.04
else:
  tax = price * 0.06

2. A variation to the business logic is introduced. A pattern might be emerging. We leave it alone.

if price < 2000:
  tax = price * 0.03
elif price >= 2000 and price < 6000:
  tax = price * 0.04
else:
  tax = price * 0.06

3. The business logic shows up again in a 3rd instance. We talk it out with the domain expert, we agree that it is a valuable aspect of the domain. We revise the model and refactor in an attempt to reduce overall complexity.

tax_schedule = new TaxSchedule(...)
tax = tax_schedule.calculate_tax(price)

Notes about the coding context  

2 occurrences should feel like a tingle and there is often opportunity to easily remove duplication. However, in many cases it is too early to invest in more elaborate solutions.

Example applied to process  

The logic is similar when dealing with a process in general:

1. A situation occurs a first time; it is dealt with in an adhoc manner.
2. A similar situation occurs; we use the notes of the previous instance to guide resolution.
3. The situation occurs a third time; we consider the likelihood of further occurrences and implement a solution based on how likely and how often we believe it will happen in the future. The solution could be to document the process or to automate it.