We were rolling out Windows NT across all German sites, it was not a small undertaking. We had thirteen locations, seven major depots and six smaller branches, all connected in a WAN by various means like isdn and leased lines. You could achieve about 64 kbits for a branch office connectivity which was enough for terminal sessions but not much else.
We were trying to build, across that fragile infrastructure, something that had never existed before: AA enterprise computing environment, spanning two completely different technology worlds.
Two Worlds, One Organisation
The organisation ran on two platforms that had almost nothing in common.
The first was UNIX, specifically SCO OpenServer, running Informix for accounting and payroll and a separate system on an IBM AS/400 for logistics and parcel operations. These were the digital brain of the business. Powerful, stable, text-based systems operated by people who had spent years building digital pipelines. For them, the command line and shell scripts was not an interface, it was the system. You did not click things into existence. You chained and pipe commands together scheduled and and build them to create fast and reliable transactional systems.
The philosophy in that world was simple and deeply held: if you do something twice, automate it. Every repeatable task was decomposed into small executable steps and bound together into scripts. Those scripts became extensions of the administrator's own thinking invisible machinery that ran quietly in the background while the humans did more interesting things.
The second world was Windows NT (AKA Not There), which we were now rolling out to end-user desktops and file servers across every site. It was a genuinely capable platform, but it was also new, and it carried the slightly unfinished quality of something still finding its footing (hence the nickname Not There yet). Configuring TCP/IP was manual and fussy. Name resolution mixed HOSTS files, early DNS, and proprietary Windows mechanisms in ways that required patience. Multiple network stacks could coexist on the same machine, which was either flexible or chaotic depending on your mood.
The UNIX administrators were politely sceptical or outright hostile. One of them, encountering a Windows desktop for the first time, spent a few quiet minutes moving the mouse around the screen visibly curious about its responsiveness then briefly explored the SCO UNIX graphical environment, acknowledged that Windows looked "prettier" and returned to his command line (probably for the rest of his career).
He was not wrong that the CLI was more powerful for what he did. He was just not looking at the larger picture.
The Problem Nobody's System Solved
What became clear, fairly quickly, was that neither world could do what the business needed on its own.
The UNIX systems held the operational truth of the organisation, the parcel data, the financial records based in the captured scanning history. The Windows desktops were where people increasingly worked, where files were created, where decisions got made and that data was made visible with pretty line graphs and pie charts. Getting those two worlds to share state reliably, across thirteen sites connected by links that were sometimes slow and occasionally temperamental, was not a problem that any platform had a built-in answer for.
So we built the answer ourselves, out of whatever was available.
The most demanding version of this problem was backups. Every site had to be backed up nightly. Every backup had to be verifiable not just assumed to have worked, but confirmed. And that confirmation had to be visible centrally, across the entire organisation, so that we were not discovering failures only when we needed to restore something.
The solution we built was not elegant. But it worked, and it kept working.
A scheduled job triggered Microsoft Access at each site. Access launched automatically and ran a macro. The macro executed VBA scripts. The scripts called batch files. The batch files ran Windows NT Backup. When the job finished, the resulting success or failure was written into a plain text file on the local machine.
That text file was small enough to travel across a 64 kilobit line without fail.
Those files were then synchronised to a central location, so that every morning we could see the backup status of the entire organisation in one place. Not through a dashboard or a monitoring platform but through a folder of text files, each one representing a site, each one telling you what had happened overnight.
It was primitive. It was also, in retrospect, a working implementation of distributed observability built from Access macros, batch files, and a replication mechanism held together by scheduled tasks and goodwill.
What I Was Actually Learning
At the time, I thought of this work as practical problem-solving under constraint. You had limited bandwidth, mismatched systems, no budget for anything sophisticated, and a business that needed things to work reliably every day. So you used what you had.
What I was actually learning, without having the vocabulary for it yet, was how to make systems that were never designed to cooperate behave as though they were built together.
That required thinking across both worlds simultaneously. The UNIX side taught me composability, the discipline of building complex behaviour from small, reliable, independently testable parts. The Windows side taught me something unexpected: that even a graphical, apparently non-programmable system had deep layers of automation hidden inside it. Access was not just a database. In the right hands it was an orchestration engine with memory and logging. VBA bridged the gap between the visible application and the underlying operating system. SQL shaped and transformed data at a scale that no spreadsheet could approach.
Across those years I became, without planning it, someone who was equally at home in both environments. Neither was foreign. Each was simply a different way of expressing the same underlying goal: make the system behave predictably, under real conditions, when it matters.
The Skill That Transferred
That combination of UNIX automation thinking, Windows system integration, SQL-driven data pipelines, and the pragmatism of building reliable things from unreliable parts turned out to be more transferable than any individual technology I learned during that period on its own.
Every platform I have worked with since has had the same fundamental shape: a capable core, surrounded by a gap between what the system can do and what a specific organisation needs it to do. Closing that gap is always the real work. It requires understanding both the system's possibilities and the organisation's actual constraints. And the solution is always to build the connective layer that makes the two fit together.
Some of those layers have been elegant but mostly improvised and all of them have worked because they were built by someone who had thought carefully about where the real friction was.
The Same Pattern, Thirty Years Later
When I look at what organisations are trying to do with AI today, I see the same landscape I was standing in during early nineties.
The capability is genuine in places, remarkable. But the gap between what the models can do and what any particular organisation needs them to do reliably is large, and it is not closing by itself. What closes it is the same thing that closed it then: careful design of the layer in between. How data flows in. How context is structured. How outputs connect to downstream processes. How the whole pipeline behaves when something goes wrong.
That work is not about the model. It is about understanding the organisation, the data, the constraints, and the failure modes and building something that holds together under those conditions.
We did it with shell scripts, VBA macros, and text files replicated across thin WAN links all fueled by creativity.
The tools are different now in some ways more advanced in some ways more experimental. But the shape of the problem and how to solve is still very similar if not the same.
This post is part of a series drawing on three decades of systems work — from 1990s logistics infrastructure to modern AI workflows. Previous posts: The Day a £5,000 Controller Changed Everything and IT Forensics And the Disappearing Parcels.