Why You Should Build Software Like You’re Fleeing A Desert Island

Let’s say you and 200 other people were on a plane that had to make an emergency landing on a desert island. All radio communication is dead and there’s nothing of use on the island…because it’s a desert island. But in the distance, you see a lush tropical island with tons of vegetation, banana trees and shelter. You know the only way to survive is to get everyone to that island.

So, you come up with two possible strategies to get everyone to that island:

1. Build one big boat that can fit everyone in one trip.
2. Build many smaller boats that can bring a few people over at a time, in multiple trips.

The “Build One Big Boat” Strategy

To get everyone off the island in one big boat, you estimate that it will take six months to build it. After eight months (instead of six), 50 people die of starvation before the Big Boat is (sort of) ready. Nonetheless, you and the rest of the survivors cast off on the Big Boat. Halfway to the tropical island, the Big Boat sinks and 100 people drown and/or get eaten by sharks.

The remaining survivors safely swim the rest of the way to the tropical island. Shortly after you arrive, you find a small airplane in good flying condition—except there’s no fuel. They all look back at the desert island where the crashed plane is laying there…full of fuel.

Eventually, everyone dies anyway. Disturbing, I know.

The “Build Many Small Boats” Strategy

What if, instead of building one big boat, you immediately started building many small boats. The first small boat quickly sinks as soon as it’s put in the water. You learn why it sunk so now you know how to make a better boat. The second small boat sets off (while a third boat is being built) and three people make it to the tropical island. When they arrive, they find the small airplane and they tell the people in the third boat to return to the desert island to get fuel from the crashed plane.

Eventually, everyone survives.

So Which Software Strategy Would You Use Now?

One Big Software Build

If your first software build is packed with every possible feature, it will:
  • Inevitably take far longer to build than you had originally planned (read: “Your Estimates Suck” from the book, REWORK)
  • Provide no insight into real-world usage and ways you can learn how to make it better (floating Vs sinking)
  • Limit your ability to learn and change the features you really need and eliminate the ones you don’t (can’t return for fuel)
  • Force you to over-invest in building a product before you can prove there’s even a business for it (6 months building and still no boat)
  • Carry more risk and potential to fail (sunken boat)

Many Small Software Builds

The first small boat can be viewed as your prototype. It sunk – but you quickly learned why and you used those learnings to build a better boat. As you get each small software build into the hands of real users, you are also able to quickly learn:
  • How to make the software more usable
  • What features should and should not be included in each build
  • How to make the infrastructure perform better
  • How to make your business even more successful

The Moral of the Story

Many small builds will help you succeed. One big boat will get you killed.