Build Software Like You’re Fleeing A Desert Island

Imagine that you are the captain of a commercial airliner that has crashed on a desert island, and 200 people have survived. Food is scarce, there’s nothing but sand and people are going to start dying if you don’t get them off the island.

In the distance, you see a lush tropical island with tons of vegetation, banana trees and shelter. You know the only way to save everyone is to get everyone to that island. So, you come up with two possible solutions:
1. Build one big boat that can fit everyone in one trip.
2. Build many smaller boats that can bring everyone over in multiple trips.

The Big Boat

You decide to build one Big Boat to get everyone off the island and 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 finally ready.

Finally, you get the remaining 150 survivors on the Big Boat and you cast off. Halfway to the tropical island, the Big Boat sinks and 100 people drown.

The remaining 50 survivors make it safely to the tropical island and, shortly after they arrive, they find a small airplane in good flying condition—except there’s no jet fuel.

Eventually everyone dies anyway.

Many Small Boats

Instead of deciding to build one Big Boat, you immediately start building many small boats. As soon as the first boat is done, you send three people in it to the tropical island. The first small boat sinks but it’s small so the boat sinks before they make it very far and the people are able to swim back to the desert island. The people on the first boat tell everyone why the boat sank so they can learn how to make a better boat. So a 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 in good condition and they tell the people in the third boat to return to the desert island to get fuel from the crashed commercial airliner.

All 200 people survive.

How Does This Compare to Building Software?

The Big Software Build
If your first 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 jet 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. You can let a few people use your prototype so you can learn how to make it better. It will be quick and easy to improve upon because it’s, well, small. As you roll out each small build you are constantly learning: