Why Infrastructure Companies Think in Decades
The different time horizons required when building systems that sit at the bottom of the stack.
The Lindy Effect in Tech
The longer a technology has been around, the longer it is likely to stay around. SQL, TCP/IP, POSIX—these are the bedrock. When choosing dependencies for long-term infrastructure, we favor the boring, the proven, and the standard. Novelty acts as technical debt in this layer.
We intentionally choose primitives that have survived the hype cycle. This ensures that the tools we provide to you won't be deprecated next year because the maintainer got bored. Reliability is 90% predictability.
API Design as Geologic Layers
Changing a public API for an infrastructure provider is akin to moving a tectonic plate. It causes earthquakes for your customers. Therefore, we must design APIs not for the features we have today, but for the abstractions we might need ten years from now. We prefer broad, generic primitives over narrow, specific use-cases.
Once an API is public, it is forever. This constraint forces a level of rigor in design that is uncommon in rapid application development. It forces us to "measure twice, cut once" in a world that usually celebrates "move fast and break things."
We build for tomorrow by respecting the constraints of yesterday. To think in decades is to humble yourself before the complexity of time.