# Why Version Control Exists: The Pendrive Problem Imagine you and your three friends Ironman, Batman and Superman working on a college project. You write some code on your machine, save it to a pendrive, and hand it to Ironman. He makes changes, saves it back, and passes it to Batman. Batman adds his part and gives it to Superman. Sounds cool and simple, right..??? Now imagine this → Ironman accidentally overwrites your best code while adding his feature. Batman creates a different version because he didn't like Ironman’s changes. Superman loses the pendrive at the college canteen. And suddenly, nobody knows which version is the "correct" one, or if any version even exists anymore. Welcome to the chaos that existed before version control systems. ## The Pendrive Era of Software Development Before tools like [Git](https://technocycho.hashnode.dev/git-for-beginners-basics-and-essential-commands) became standard, developers actually worked this way. It wasn't pendrives for everyone (though some used them), but the principle was the same: manual file management that depended on copying, renaming, and hoping for the best version than the previous one. Here's what a typical project folder looked like: ![A diagram displays a project folder containing six JavaScript files: code_final.js, code_final_v2.js, code_final_ACTUAL.js, code_final_latest.js, code_latest_final_USE_THIS.js, and code_final_v2_john_edits.js.](https://cdn.hashnode.com/res/hashnode/image/upload/v1768560649695/2a3cbd9d-a499-445a-aba5-59c7117386ea.png align="center") If you've ever worked on a document or project and ended up with names like `report_final_FINAL_v3.xyz`, you understand the problem. ### How Teams Shared Code Developers used several methods to collaborate: → Email attachments: "Hey, I updated the login feature. See attached `app_`[`v7.zip`](http://v7.zip)" → Shared network drives: Everyone accessed files from a central server, but with no locking mechanism, people would overwrite each other's work constantly. → Physical storage devices: USB drives, CDs, and even floppy disks were passed around like relay batons. → Manual backups: Developers would create dated folders like `backup_2024_01_15` hoping they'd never need them but the opposite has to happen at some point ;-) Actually → version control - was literally in the filename. ## The Problems That Made Developers Pull Their Hair Out * ### Overwriting You spend four hours perfecting a feature. You save your file and take a lunch break. Your teammate opens the same file, makes their changes, and saves it. Your four hours of work? Gone. Overwritten. No warning. No mercy. **Real scenario:** * Sarah creates `website.html` with a beautiful navigation bar. After few hours, Mike opens `website.html`, adds a footer, saves. On Tuesday, Sarah discovers her navigation bar code has vanished. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768563928770/f3d47646-48b9-4e4a-9914-a33bfbb2a2ba.png align="center") * ### Unknown Latest Version Your team has six versions of the same file. Each person claims theirs is the latest. One has the bug fix. Another has the new feature. A third has both but also has some broken code. Also a backup exists. Nobody knows which one to use for further development or to be used for production.. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768562693157/f123145e-faba-422b-b921-a2d646d944b4.png align="center") ### Lost Changes Forever Remember that brilliant solution you coded last week? It worked perfectly. But it's not in the current file. You try to remember what you did, but the exact logic is fuzzy. You search through old email attachments and backup folders. Nothing. The code is lost forever because there's no history of changes. ### The Blame Game A critical bug appears in production. Who introduced it? When? What exactly changed? With files being passed around and overwritten, there's no way to trace who made what change. The investigation takes hours, sometimes days. ### Fear of Experimentation Want to try a risky new approach? You'd have to create yet another copy: `app_experimental_dont_`[`use.py`](http://use.py). Want to test three different solutions? That's three more files cluttering your folder. Developers became afraid to experiment because managing all these versions became impossible. ## The Pendrive Analogy in Modern Teams Let's say you and two friends are building a website together → **Day 1:** You create the homepage and save it to a pendrive and u handed the pendrive to Friend A. **Day 2:** Friend A adds a contact form and updates the pendrive. Passes it to Friend B. **Day 3:** Friend B redesigns the homepage completely (goodbye to your original design) and adds a gallery. Saves to pendrive. **Day 4:** You get the pendrive back. Your original homepage is gone. Friend A's form is there but broken. Friend B's gallery looks good but wasn't reviewed by anyone. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768622504621/d075fce6-3e3b-44f1-a0b0-5e2d51a13dc4.png align="center") **Questions nobody can answer:** * What did the homepage look like two days ago? * Who broke the contact form? * Can we undo Friend B's redesign and keep just the gallery? * What if Friend B lost the pendrive? This is exactly how software teams struggled before version control. ## Why This System Couldn't Scale The pendrive/email/folder-naming approach might work for: * A single developer working alone * Very small projects * Short-term assignments But it completely falls apart when: * Multiple people work simultaneously * Projects last months or years * Code needs to be deployed to production servers * Teams are distributed across different locations * You need to maintain multiple versions (production, development, testing) ## Version Control Systems Version control systems (VCS) like Git, Mercurial solved every single problem mentioned. Like changes are tracked and can be merged intelligently. Every change has a timestamp, author, and description/ Comment. Complete history of changes/ development is preserved forever.Exact changes and authors are tracked automatically.We can experiment freely with branches, roll back anytime to the point where we need or go forward and merge the current one.Version control system (VCS) didn't just make collaboration easier. It made modern software development possible at a larger scale. ## Fast forward to Modern day development — Today, version control isn't optional. It's fundamental. Whether u are building a mobile app, a website, or enterprise software, you're using version control. Even solo developers use it because: * Mistakes happen and it will help them undo it * No fear to experimentation as everything will be safe * past self's work is preserved * collaboration might happen in the future This problem taught the tech world a crucial lesson → you can't manage complexity with manual file copying. u need systems designed for collaboration, history, and safety. And that's exactly what version control provides.