Rule of 3

The Rule of three is a simple algorithm to handle YAGNI (You ain't gonna need it). If you haven't heard of YAGNI it's a statement to prevent over-engineering. Most problems people worry about don't happen, which is why you ain't gonna need it! But, people instinctively solve for requests that might happen. This is seen in engineering, but also in other areas of life. There is a lot of anxiety around things that might happen.

Dealing with hypotheticals results in wasted effort and complexity. When people engineer for all possible problems; they build complex systems; and it takes an eternity to build.

Many people mistakenly believe that dealing with imagined problems is a sign of great engineering. I've seen teams spend weeks solving problems that if they occurred would have a negligible impact on the company.

Great engineering is keeping things simple. Life typically follows the Pareto Principle where 80% of the costs go towards 20% of the problem. This means that 20% of the cost results in 80% of the value.

The Rule of 3 Algorithm

1) Do it dumb.

2) Do it dumb but think about doing it smart.

3) Do it smart.

Rule of 3 in a few different contexts.

General Requests

1) The first time you have a request for something: Do it quick and dirty.

2) The second time you have a request for the same thing. Keep it simple but think about a complete solution.

3) The third time you have a request for the same thing. Do the full solution.

Reports

1) First request for a report do it manually

2) Second request do it manually but think about how to automate.

3) Third time build an automated report.

Code

1) First time you code a user story - hard code it.

2) The second slightly different user story - slap an "if" statement in the code and think about how to refactor.

3) Third user story along the same lines; abstract and refactor.

A Product Launch

1) The first batch of customers provide a manual experience and verify your hypothesis.

2) The second batch of customers, tweak the process based on learnings but keep it manual. Maybe automate some low hanging fruit.

3) The third batch have your engineers automate the manual bottlenecks (Not every manual step. Just the 20% of manual steps that takes up 80% of the handholding). This way you can put engineers on the biggest pain points to scaling and grow as they engineer each bottleneck. If the product is a hit you'll have the funds to build out the full solution.

Why does this algorithm work? The algorithm allows you to spend the least amount of effort on the 80% of things that don't matter. The second time when you think about the problem it allows you to solve for the issue in your mind without spending time implementing. Plus, you have two concrete examples of the problem. While waiting on the 3rd time your solution will improve in your subconscious. By the 3rd time when you implement the solution; you are doing the hard work after seeing real-life evidence that this is most likely part of that valuable 20%.

Why do people over-engineer? I think it's human nature to fear pain more than enjoy pleasure. This fact is often used in sales and marketing. We fear the embarrassment or judgement of our peers if we miss a problem. So, we waste resources solving for as many mistakes we can think about. I'm not sure if this is true; but I heard statistically football teams should go for it on 4th down way more frequently than they actually do. Coaches know this; but coaches don't go for it because the times they miss; will get them slammed by the fans. The times they do make it fans feel they were reckless.

I'll talk more about psychological safety in a future article. For now, this is one of the reasons psychological safety generally results in winning teams. People in positive environments don't waste 80% of their time covering 20% of their ass. In winning teams people are still human and probably spend 20% of their time covering 80% of their ass; which leaves them with 80% of their time to go after winning with most of their ass covered.

Warning: if you are building a rocket or dealing with something like a medical system that must be 100%, you should deal with all hypotheticals - and include backups for those. In those 100% situations; the solutions are expected to be complex, and expected to take a lot of resources. This article is not for those situations. Use judgement as this article is for the 80% of situations it applies to.

Questions: In what areas of your life are you too cautious? What 20% can you drop to save yourself 80%? What 20% can you go after to get 80%? How is the psychological safety of your team? Have you over-engineered something? Why?