Based on a LinkedIn post originally published on 3 April 2026
In the early 1990s, while living in southern Brazil, I worked for a software-development company that produced hospital-administration systems in partnership with IBM.
Through that relationship, we had access to IBM RS/6000 systems running current versions of AIX.
Our product was deployed across Brazil. That national reach introduced scale, operational pressure and responsibility very quickly.
One of the largest engineering challenges was not writing an individual piece of code. It was coordinating the work of several developers and integrating their changes into one reliable product.
When several people can write code successfully, the difficult problem becomes ensuring that their individually correct changes can coexist safely.
The coordination problem
Developers needed to work in parallel.
They required enough independence to make progress without waiting continuously for one another, but the company still needed a consistent shared codebase from which the product could be built and delivered.
The workflow needed to support several operations:
- developers obtaining the latest shared code;
- local changes being developed and tested independently;
- approved work being returned to the central environment;
- conflicting changes being identified;
- and developer environments remaining sufficiently synchronised.
Developer A ----\
\
Developer B -------> Shared product code ----> Build and delivery
/
Developer C -----/
Each developer can change the product.
Not every combination of changes is safe.Without a reliable integration model, speed in individual development could create instability in the shared product.
The tools did not match the workflow
I examined several available options, including mechanisms built into the development tools themselves.
None matched our needs closely enough.
A tool might support shared files but provide weak control over when a change became visible. Another might support central storage while making independent work cumbersome. The technical capability existed in fragments, but the complete workflow did not.
Eventually, I realised that we already possessed the required primitives:
- a central code location;
- network connectivity;
- local developer environments;
- file-comparison and transfer utilities;
- shell scripting;
- and a team capable of following explicit integration rules.
The missing component was not another fundamental technology. It was a workflow connecting the pieces.
Building the workflow with shell scripts
Using shell scripting, I created a small collection of Bash-based workflows for managing code movement between developer environments and the central repository.
The scripts handled operations equivalent to:
PULL Obtain current shared changes WORK Develop and test locally CHECK Identify differences and possible conflicts PUSH Return proposed local changes COMMIT Accept approved code into the shared repository SYNC Bring development environments back into alignment
The terminology may resemble modern version-control commands, but the implementation was much simpler. This was not Git before Git, nor a complete modern distributed version-control system.
It was a purpose-built integration workflow created from the tools available at the time.
The resemblance lies in the working principles—not in a claim that the implementation possessed every capability later provided by Git.
Independent work with explicit synchronisation
The workflow allowed developers to make progress within their own environments.
Changes did not become part of the shared product merely because someone edited a file. Synchronisation was an explicit action.
+-----------------------+
| Central repository |
| Approved shared code |
+-----------------------+
^ |
push | | pull
| v
+----------------+ +----------------+
| Developer A | | Developer B |
| Local changes | | Local changes |
+----------------+ +----------------+This separation created a useful boundary:
- local work could remain incomplete without destabilising everyone else;
- developers could synchronise deliberately;
- and shared code represented a more controlled state than an arbitrary local workspace.
The scripts did not remove the need for communication. They gave that communication a technical structure.
Rules mattered as much as scripts
The automation enforced basic rules about what could be shared, when it could be shared and how conflicting work should be handled.
A coordination system requires more than file movement. It needs a shared understanding of state.
LOCAL STATE A developer's current work May be incomplete or experimental PROPOSED STATE Changes prepared for integration Must be compared and reviewed SHARED STATE Accepted code used by the wider team Must remain coherent and buildable
Without these distinctions, the central repository would become only a network directory into which everyone copied files.
The value came from the transition rules between the states.
Conflict is a coordination signal
When two developers change the same area of code, the technical conflict is often evidence of a coordination issue.
A conflict may mean:
- both developers are solving related problems;
- ownership is unclear;
- the code is too tightly coupled;
- one person began from an outdated state;
- or a shared design decision was never made explicitly.
The script can identify that two versions differ. It cannot decide automatically which business behaviour is correct.
Tools detect conflicting representations. People resolve conflicting intentions.
This remains true with modern version-control systems. Sophisticated merge algorithms can combine lines of text while still producing logically incompatible behaviour.
The shape of modern distributed version control
Years later, tools such as Git formalised a much richer model of distributed development.
Modern systems provide:
- local repositories containing complete history;
- cryptographically identified objects and commits;
- efficient branching and merging;
- explicit remote synchronisation;
- distributed collaboration without one mandatory live connection;
- and powerful tools for tracing how the code evolved.
My scripts did not implement that complete architecture.
But the working problem had pushed us toward several of the same principles:
Work independently
|
Keep local state
|
Synchronise explicitly
|
Identify conflicts
|
Accept shared changes deliberately
|
Preserve a coherent common productConstraints reveal the primitive beneath the product
When a ready-made tool is unavailable, engineering begins with the underlying requirement.
We did not begin by deciding to create version-control software. We began with practical questions:
- How can developers work without overwriting one another?
- How can everyone obtain the accepted version?
- How can proposed changes be introduced safely?
- How can we recognise that two changes are incompatible?
- How can several environments converge again?
Those questions are more durable than any specific tool.
Git answers them far more completely than our scripts did, but the operational need existed long before the modern product.
Simple tools can be effective when the model is clear
The workflow was not elegant by current standards.
It lacked many capabilities now considered fundamental. It depended on conventions, a known environment and a team small enough to share the same working model.
Within those constraints, it was effective, predictable and fast.
The scripts succeeded because their scope was narrow:
Known developers Known AIX environments Known network Known repository Known product structure Explicit team rules
A narrow tool serving a well-understood context can provide more value than a feature-rich system introduced without a shared operating model.
Good ideas reappear
Looking back, what stands out is not that we independently invented a modern tool.
We did not.
What stands out is how frequently real constraints lead engineers toward recurring patterns:
- local autonomy;
- explicit synchronisation;
- controlled integration;
- visible state transitions;
- and reliable convergence toward a shared result.
These principles appear in source control, distributed databases, deployment systems, asynchronous messaging and many other areas.
The implementation changes because the technology and scale change. The underlying coordination problem remains recognisable.
We were not trying to invent the future. We were solving the problem in front of us. But well-understood constraints often lead engineers toward principles that outlive the tools used to implement them.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment