Why Version Control Exists: The Pendrive Problem
Before I understood what version control was, I thought it was just something senior developers used to feel organised.
Like a fancy folder system.
I was wrong.
Version control exists because of a very specific, very painful problem that every developer faces before they discover it. And once you understand that problem, the solution makes complete sense.
Let me explain it with something everyone has done.
The Pendrive Problem
Imagine you are working on a college project. You and two friends are building a website together.
You write the homepage. Your friend writes the contact page. Another friend handles the navigation bar.
At the end of the day, someone collects everyone's work on a pendrive.
Now what?
You try to combine three separate folders into one project. Someone's file has the same name as someone else's file. You are not sure which version is newer. You overwrite something by accident. One friend made changes to a file that another friend had already modified, and now one version of those changes is just gone.
By the end of the night, nobody is sure which version of the project actually works.
This is the pendrive problem. And it is not just a college thing.
This Happened in Real Software Teams Too
Before version control systems existed, professional developers faced the exact same chaos — just at a much larger scale.
Teams shared code through emails, shared drives, and USB drives. Someone would finish a feature and email the updated file to the rest of the team. Someone else would be in the middle of editing that same file and suddenly have no idea if their version was outdated or not.
Folders started looking like this:
project/
├── index.js
├── index_final.js
├── index_final_v2.js
├── index_final_v2_ACTUAL.js
├── index_backup.js
└── index_USE_THIS_ONE.js
Everyone on the team had their own copy of the codebase. Everyone was making changes. Nobody had a clear picture of what the current working version actually was.
And the worst part — there was no history.
If something broke, you could not go back and see what changed. You could not figure out who changed it or when. You just had a broken project and a folder full of files with increasingly desperate names.
The Specific Problems This Created
1. Overwriting Someone Else's Work
Two developers edit the same file at the same time. One finishes first and sends their version to the team. The other finishes later and sends theirs. The second version gets used. The first developer's changes are just gone.
No warning. No conflict. Just gone.
2. No Collaboration History
When something breaks in production, the first question is always — what changed?
Without version control, nobody knows. There is no log, no record, no way to trace what was modified and when. You are debugging blind.
3. Fear of Making Changes
This is the one nobody talks about enough.
When there is no safe way to go back, developers become afraid to make changes. They work on their local machine for days without sharing anything, because they are terrified of breaking something that they cannot undo.
Progress slows down. People work in isolation. The codebase becomes something nobody fully understands.
4. No Single Source of Truth
Every developer has their own copy of the project. Whose version is correct? Which folder has the latest working code? Is it the one someone emailed yesterday, or the one someone uploaded to the shared drive this morning?
In teams of even three or four people, this becomes unmanageable almost immediately.
The Pendrive Analogy Scaled Up
The pendrive problem does not go away just because a team gets more professional. It gets worse.
A startup with ten developers using Slack to share zip files of the codebase is just a more organised version of the same chaos. The files have better names, maybe. But the underlying problems are identical.
Someone is still overwriting someone else's work. Nobody still knows what changed last Tuesday. A developer is still afraid to touch the authentication module because last time someone did, it broke and nobody could figure out why.
The pendrive is just metaphorical now. But the problem is exactly the same.
Why Version Control Became Mandatory
At some point, the industry realised that this was not a workflow problem. It was not something you could fix by being more organised or naming your files better.
The problem was structural. Developers needed a system that could:
Track every change ever made to every file
Keep a clear history of who changed what and when
Allow multiple people to work on the same file without overwriting each other
Make it possible to go back to any previous version at any time
Give the entire team a single shared source of truth
That is what version control systems were built to do.
Git, which is the most widely used version control system today, solved all of these problems. It gave teams a way to work on the same codebase simultaneously, without chaos, without fear, and without folders named final_v2_ACTUAL_USE_THIS.js.
Final Thoughts
Version control did not become standard in software development because developers suddenly became more disciplined.
It became standard because the alternative — pendrives, shared folders, emailed zip files, and desperate file naming conventions — was genuinely unsustainable.
The pendrive problem is real. Every developer has lived some version of it, whether they realise it or not.
Version control is the solution that the industry converged on because it is the only approach that actually scales.
Once you understand the problem it was built to solve, everything about how Git works starts to make a lot more sense.
Thanks for reading.
