Where the Wall Is

The fastest way from Leesburg to McLean is Route 7, until there is traffic. Then it is Route 7 to Route 28 to the Dulles Toll Road. The map did not change. The state of the system did, and the answer changed with it. A map app solves this in a blink, and it will recompute the moment the traffic does.

Now add stops. Ten errands, any order, home at the end. That is the traveling salesman problem, the heart of routing for every delivery fleet, and it is a different kind of problem. Trying every order for ten stops means about 3.6 million routes. For twenty it is about 2.4 quintillion, which at a billion routes a second takes roughly 77 years. Each stop you add multiplies the work.

I have watched that wall from both sides. In college I built luggable computers in the Compaq form factor from the motherboard up, for a company, now gone, that sold them. In those same years I wrote code to test gyroscopes for the Hubble Space Telescope. A machine of that era strained at a dozen stops. Today's laptop handles a few more. The hardware got faster by many orders of magnitude, and it bought a handful of stops.

What moved the wall was mathematics. Brute force is the first math: exact, simple and hopeless at scale. The shortcuts, better methods and rules of thumb that find a good route without trying every order, are what let a fleet route thousands of stops. Every shortcut works because it assumes something about the problem, that the roads behave, that the pieces are independent. Most of the time the assumption holds.

That is what computer science solves for. It tells you where the wall is, what abstraction gets you past it, and what the abstraction hides. Abstraction works until physics shows up. At Three Mile Island in 1979, operators trusted an indicator that reported what a valve had been told to do, and not what it was doing. The indicator was an abstraction of the valve, and the valve was stuck open. The model was good until the day it was not.

For an investor, the lesson is a diligence question. When a team says its software will solve a problem, ask which side of the wall the problem sits on, which shortcut gets it across, and what that shortcut assumes and hides. A demo shows the small version, where everything is fast and the assumptions hold. The plan fails on the large one, or on the day the assumption does.

I learned where the wall is in my first jobs, which is why first jobs matter. This is the author's account and is not investment advice.