Or: Why the best code I ever wrote ran on a machine your smartwatch could beat in a fight
There's a YouTube channel called Dave's Garage where Dave Plummer — the engineer who wrote Task Manager for Windows NT — talks about PDP-11 assembly, the internals of early Windows, and what it actually felt like to build software when every byte was a negotiation.
If you watch it and feel a deep, almost physical recognition — like someone is describing a world you lived in but nobody talks about anymore — this post is for you.
Because here's the thing about building software in the era of constrained hardware: it made you better. Not comfortable. Not fast. Better.
The Machine
Let me set the scene.
It's 1994. The development machine is a 486DX. Maybe a 486DX2/66 if you were flush. RAM is measured in single-digit megabytes. The hard drive is 40, maybe 80 megabytes — and it is loud. You can hear it thinking.
The network is Novell NetWare over coaxial 10Base2 — the thin black cable with BNC connectors that, if one terminator worked loose anywhere on the segment, took the whole LAN down. Everybody knew which user had the wobbly connector. Nobody said anything directly. It was a different time.
FoxPro 2.6 is the development environment. Cross-platform — Windows and Mac, talking to each other over the LAN, with DDE handling IPC on the Windows side and Apple Events hacks on the Mac side. The .DBF files live on the Novell share. Rushmore query technology tears through them at speeds that seemed like witchcraft given the hardware underneath.
This is the world GalleyMaster was born into. A production automation system for independent Yellow Pages directory publishers. And it had to solve a problem that, if you described it to a computer science student today, they would immediately recognize as non-trivial.
The Problem
A Yellow Pages page is not a blank canvas. It is a constraint satisfaction puzzle with business rules, and every decision has downstream consequences.
Display ads come in as placed graphics. Each one has a text flow boundary — a shape that pushes the body copy out of the way, like water flowing around a rock. The ads have sizes: full page, half page, quarter page, business card. They have rules:
- Nothing in the gutter
- Bigger ads toward the top
- An ad must appear on the same page as its category heading
- Full page ads are the only exception to the heading co-location rule
- The text flows around everything
- Everything reflows when anything moves
- And the directory has to close — you cannot just add pages
Every page in the book was this puzzle. Hundreds of pages per directory. Multiple directories per year.
The placement function had to test candidate locations, check spatial occupancy, apply the business rules in the right order, choose the best available slot, and trigger a reflow — all before the user got impatient.
No REST API. No cloud function. No GPU-accelerated spatial index. A 486, a Novell share, and FoxPro 2.6.
What Constraints Actually Teach You
Here's what working in that environment forced you to learn, whether you wanted to or not.
You had to understand the problem before you touched the keyboard.
Today, with effectively infinite compute available for a few cents per hour, you can afford to be approximate. Throw data at a model, see what comes back, iterate. Load the whole dataset into memory and brute-force the answer. Spin up another instance if it's slow.
In 1994, you could not do any of that. If your algorithm was wrong, or inefficient, or made the wrong assumptions about the data, the user sat there watching the cursor blink while the hard drive screamed. There was no hiding behind hardware.
You had to think first. You had to understand the geometry of the page, the order in which rules should be evaluated, the data structure that would let you test occupancy quickly without scanning every pixel. The algorithm existed completely in your head before a single line was written.
That discipline — think before you type — is the single most transferable skill that era produced, and it's the one most at risk of being lost.
You had to know what the machine was actually doing.
FoxPro's Rushmore technology worked by using bitmap indexes to accelerate filter expressions. If you knew how Rushmore worked — which expressions it could optimize, which ones it couldn't, how to structure your SET FILTER and SELECT-SQL queries to stay on the fast path — your app was fast. If you didn't, it was slow, and you often didn't know why.
That was true of everything. DDE had a specific handshake sequence. Apple Events had a specific object model. Novell file locking had specific behaviors around RLOCK() and FLOCK() and SET REPROCESS that you either understood or debugged at 11pm.
The machine was not abstract. It was specific, and it rewarded specificity.
You had to make one thing do many things.
Memory and storage costs meant you could not afford redundancy. The data model for GalleyMaster had to represent a Yellow Pages ad simultaneously as a layout object, a sales contract, a production job, and an accounts receivable item — in .DBF files, without foreign key enforcement, without referential integrity, without transactions in the modern sense.
You got one record. It had to serve four contexts without falling apart.
That forces a kind of data modeling clarity that is genuinely hard to achieve when you can just add another table, another service, another database. Constraints make you find the essential shape of the thing.
The Specific Pleasure of Making It Work
There is a feeling that old-school developers know and rarely talk about because it sounds like bragging.
It's the feeling of making something work that probably shouldn't have worked.
DDE across a Novell LAN, talking to PageMaker, triggering a reflow, watching the columns land perfectly on a blank page — that worked. Apple Events on FoxPro Mac, where the documentation was somewhere between thin and aspirational, wired up to the same data on the same share — that worked.
Not elegantly, maybe. Not in ways that would survive a modern code review. But correctly. Reliably. In production, for real customers, making real money, on hardware that a 2025 smartwatch would defeat without breaking a sweat.
Dave Plummer writing Task Manager to fit in the constraints of Windows NT's kernel architecture. The Apollo guidance computer doing orbital navigation in 4KB of RAM. The Voyager probe, still transmitting, running on 1970s hardware across 15 billion miles of empty space.
The pattern is always the same: the constraint was the teacher.
What We Risk Losing
This is not a complaint about modern development. Modern tools are extraordinary. The ability to spin up a Postgres instance, deploy a containerized service, and iterate on a UI in hot-reload in the same afternoon is genuinely amazing and produces real value fast.
But something specific gets lost when compute becomes free.
When you never have to think about what the machine is actually doing, you stop thinking about it. When you can always add more memory, you stop thinking about what's in memory. When a slow query can be fixed by scaling horizontally instead of fixing the query, you stop writing good queries.
The muscle atrophies.
The developers who came up in the constrained era carry something in their heads that is hard to teach and easy to lose: an intuition for what a computer is actually doing at any given moment, and a reflex to make it do less of it.
That intuition is worth preserving. Not as nostalgia — the 40MB hard drive was not better than an SSD, full stop — but as a discipline. As a habit of mind.
Think before you type. Understand the problem before you touch the keyboard. Make one thing do many things well. Know what the machine is actually doing.
Those lessons came from scarcity. They apply in abundance too.
The Thread Continues
GalleyMaster is gone now. The Yellow Pages industry it served is gone too — gutted by the internet inside of a decade, multi-billion dollars of annual revenue reduced to a historical footnote faster than anyone thought possible.
But the thinking that built it didn't go anywhere.
DataPublisher for Word is the same core idea on a 2025 platform: structured data, business rules, automated document generation, distribution at scale. The placement algorithm became a template engine. The DDE connection became Microsoft Graph. The Novell share became cloud storage.
Same problem. Thirty years of better tools.
And somewhere, Dave Plummer is writing PDP-11 code on YouTube and a generation of developers who never touched a BNC connector are watching, rapt, because they recognize something in it.
The constraint was always the point.
Richard Roberts is the founder of DataPublisher LLC. He has been making data flow into documents automatically since 1994, starting with a 486, FoxPro 2.6, and a very loud hard drive.