Email Attachments: The Original Version Control
Imagine you decided to develop some crazy software before 2005. Eventually, the codebase grew to such an extent that it became difficult for you to maintain it all by yourself, so you decided to ask another developer friend who lives in another city to collaborate with you on the same software. Now you need to share all of your code files with your friend.
You manage to share those files through email, and you, along with your friend, start working on the same project. After a few weeks, your friend sends you the updated code files via email, and now you have two versions of the same software. One, which you were working on and the second, of your friend’s.
Here, the actual problem arises: how to determine the exact changes you and your friend have made and which one to keep.
At this point, things get messy fast.
You open your friend’s email attachment and stare at a folder full of files that look exactly like yours. Same filenames. Same structure. No obvious labels screaming “THIS IS WHAT I CHANGED.” Now comes the fun part, which is comparing.
You start opening files one by one, scrolling line by line, trying to remember whether that function was yours or theirs. Maybe you copy some parts from your version, paste some from theirs, and hope nothing breaks. Sometimes it works. Sometimes the app refuses to run, and you have no idea why, because you just Frankenstein’d two codebases together at 2 AM.
And this is still the best-case scenario.
Now imagine both of you changed the same file. Maybe even the same function. Maybe in slightly different ways. Who wins? Your logic or theirs? Do you manually merge it? Do you trust memory? Do you flip a coin and move on?
There’s also no safety net. If you mess up while merging, the original versions are gone unless you made backups. And if you did make backups, they probably look like:
project_old
project_old_2
project_old_2_fixed
project_latest_final
Congrats, you’ve invented versioning. Poorly.
The real problem here isn’t email or distance or even collaboration. It’s the complete lack of history. You don’t know what changed, when it changed, or why it changed. You don’t know who introduced the bug. You don’t know which version was actually working last. All you have are folders and vibes.
As more people join the project, this approach collapses entirely. Files get overwritten. Changes get lost. Someone forgets to send an email. Someone edits an outdated copy. Suddenly, half the team is building features on code that no longer exists.
This is the moment where people realised they weren’t just sharing files anymore. They were sharing responsibility, decisions, and mistakes. And doing that over email attachments was never going to scale.
The problem demanded a system that could track changes instead of replacing them. Something that could show differences instead of hiding them. Something that let multiple people work without stepping on each other’s toes, and still allowed everyone to rewind time when things went wrong.
That problem is why version control exists.
