On False Economies of Scale (aka, The Joy of Spikes)
About: technical proof-of-concept, mostly; and polar exploration, slightly.
When advocating for proofs-of-concept, I sometimes quote the (true) story of the Northwest Passage. It goes like this.
In the 1800s, Europe’s prosperity relied on ocean trade with China and India. The available routes were long and arduous — all the way around Africa, or via the tip of Chile. If a short passage could be found north of Canada, imported goods would become cheaper, and western power would project more easily onto Asia.
The British Admiralty commissioned Lord John Franklin to seek the Passage. He brought two large battleships, 130 men, and enough tinned rations for several years. They steered for Labrador. When pack ice surrounded them, they tried to ram their way through. When some curious local Inuits approached their ships, the crew shot them dead. While trapped in ice over two winters, Franklin and his whole crew perished, horribly.
Some years later, Roald Amundsen went exploring those same waters, taking another approach. He took a small fishing vessel designed for Arctic waters, and a crew of 5. Iced in over the first winter, they talked and traded with the natives, and learned how to make effective dog sleds, kayaks and protective clothing. Before navigating narrow straits and ice floes, they scouted in their kayaks for a safe channel. Inuit hunting skills allowed them to avoid the malnutrition that had plagued Franklin’s expedition. Eventually, they found the Northwest Passage, sailed safely into the Pacific, and on to San Francisco.
The skills Amundsen learned on that voyage later helped him become first to the South Pole.
There’s a very human tendency to seek safety in numbers. We might imagine that technical uncertainties can be resolved best by using all resources available. Even though we know that bigger doesn’t always mean better, we might believe that we can avoid blame for a failure by showing that we invested a great deal of time and effort in failing. Many managers have rejected simpler, cheaper, custom solutions to business problems because “nobody ever got fired for buying Microsoft”. Many project managers and software architects have commenced a full build before knowing their plan was feasible — out of fear that doing too many PoCs or ‘spikes’ could signal incompetence or excessive risk.
I wonder if Lord Franklin’s logic was similiar, when he led so many navymen into terra incognita? If he couldn’t find the Passage after several years, at least nobody would accuse him of being under-resourced, or of not giving it a darn good try?
The fail-fast, exploratory, quick spike is king.
So, do that technical spike. Explore your options. Talk to people who’ve faced similar challenges. Do just enough to prove that your approach is feasible. You can afford to commit one or two of your best engineers for a few days, to attempt something that might not work out at all. The alternative is nearly always worse.
