We have written about how the operations of finance were rebuilt in the 1990s. Beneath those operations sat the machines that ran them, and the gap between the hardware of that period and the hardware of today is wide enough to deserve its own account. A server in 1998 and a cloud instance in 2026 are not two points on the same scale. They differ in kind, and the engineering each one demands differs in kind with them.
Computing under scarcity
Compute was a budget rather than an assumption. A dataset that now resolves in seconds on a laptop took hours on the Unix workstations of the period, and that single fact shaped how work proceeded. Experiments were rationed. Long runs were scheduled for nights and weekends when machines stood free. Memory was counted carefully, storage was finite in a way that disciplined every design, and a network that dropped messages under load was a problem the engineer solved rather than a property the platform guaranteed. Databases failed often enough that a skilled administrator stayed close to every production system, restarting and recovering by hand what modern infrastructure now repairs without anyone noticing.
Software built from first principles
Software matched the hardware. Standard utilities that ship with every platform today had to be written by the people who needed them. A reliable socket listener in Java that did not lose messages under load was hand-built and hand-tested, often by breaking the connection deliberately and watching what happened, since no library yet wrapped the work for you. Database access from a high-level language was a recently solved problem rather than a given, with JDBC newly arrived and a crash-prone engine such as Sybase underneath. The integration technologies of the day, CORBA and the early message buses chief among them, were young, and an engineer learned them in the same months they shipped production systems on top of them, with vendor manuals, a few books, and a colleague down the corridor as the available sources. Glue code was not a minor category of work. It was most of the system, and writing it well was the craft of the period.
What abundance gave, and what it quietly removed
Every one of those constraints has since lifted. Compute is effectively unbounded for most purposes. Storage is cheap and elastic. Databases manage and heal themselves, and the administrator’s role has moved from constant operational rescue to strategic design. Libraries now handle the socket layer, the connection pool, the retry logic, and a hundred other things that once had to be built by hand. The gains are real, and we would not trade them.
Abundance carried a quieter cost. Operating close to the machine produced an awareness the constraints made compulsory. An engineer who had written a socket listener by hand, watched a database fail under load, and been paged to restart it on a Wednesday afternoon understood the failure modes of their systems in a way comfortable abstractions no longer require. We do not romanticise the scarcity. The present is better in almost every measurable way. The habit worth carrying forward is the one scarcity enforced: treating compute, memory, latency, and failure as real costs to be understood rather than properties the platform is assumed to handle. The engineers we most admire still reason that way, and their systems are sturdier for it.