1. Story Time: The Whole Decade of The 1990s

The decade of the 1990s was a pivotal time in software development history.

Software technology development was rapidly gaining momentum in the United States, and India was also opening its doors to capitalize on the immense opportunity and potential in Software Development and Information Technology. Everything was accelerating fast - growth, hiring, projects, and the pace of delivery.

But in parallel, a silent problem was also growing inside software development centers - a problem that almost every organization faced at some point:

➤ The code on which multiple software developers were working simultaneously was getting difficult to manage.

The more software teams expanded, the more this problem started showing up. Code collaboration started becoming messy. Codebases started becoming inconsistent. And this is where our story begins - with a problem called:

“Code Going Out of Sync”

But wait - what does “code going out of sync” actually mean?

Let’s understand this term, because this becomes the triggering point of our story - and eventually leads to the invention of something that left a pivotal mark in the history of software development.

2. Code Going Out of Sync (The Root Problem)

Two people : Person-A and Person-B - were simultaneously coding on the same Project.

Since both were working in parallel, the code written by them was dependent on each other.

Here’s what happened:

• In the morning, Person A wrote some code.

• At noon, Person B took that morning code as the base and started shipping a new feature over it.

But meanwhile:

• Person A realized his morning code had a few issues.

• So A started tweaking the same code again and brought in necessary changes in the afternoon…

…without realizing that Person B had already taken that morning code as the base for his own feature.

By evening:

• Person B was ready to ship the new feature based on A’s morning code.

• But Person A had already revamped the base code completely because it was buggy.

Now when they met:

• B realized the base code on which he built the feature was no longer valid.

• And because the base code was revamped, the feature couldn’t be shipped anymore.

So both efforts went in vain:

• A’s base code couldn’t be shipped as it needed fixes.

• B’s feature couldn’t be shipped because it was built on an outdated / faulty base.

This “code out of sync” problem became common in teams and organizations. And to cater to this issue came the invention of a solution that tracked code changes.

3. “Software inside Pen-drive to track”

• Before even using a pen-drive tracking software, developers tried solving this problem in a very manual way. They would send code over emails, share code using pen-drives, and store multiple copies inside folders with names like final, final_v2, final_latest, latest_final, final_final, etc. But this only increased confusion - nobody could confidently say which file was the correct base code, and one wrong attachment or folder copy could again push the code out of sync.

Here came the first solution to this problem.

To solve the out-of-sync issue, A & B late in the night went to their nearest computer systems market and installed a tracking software in their pen-drive. This tracking software would keep records like:

• on which date and time

• which lines of code were added

• who added them

• what was deleted and when

Now they felt ready to work on the project again.a

4. The Tracking Solution Works… But a New Problem Appears

The next morning:

• A optimized the code written by him last evening.

• He put that code inside the pen-drive and gave it to B.

Then:

• B used that code as the base code,

• developed a feature on top of it,

• pasted his updated code into the same pen-drive,

• and returned it to A in the evening.

In the meantime, A was busy dealing with clients from noon to evening to figure out new features needed by the client.

The client wanted two new inter-dependent features, and A decided to ship them by tomorrow morning. His plan was:

• he will work on one feature

• B will work on the other feature

• and both will ship it by morning

These inter-dependent features were:

• feature alpha

• feature beta

That day’s work went fine because A’s morning code was stable. The feature made by B worked seamlessly and was shipped successfully.

After shipping, they immediately started working on feature alpha and beta due to the deadline.

5. The Bigger Problem: Collaboration Bottleneck

A started building feature alpha while B started with feature beta.

But midway:

• B reached a point where he had to write code that had dependency on feature alpha.

• Without integrating that dependency, B could not proceed with beta.

• But alpha was still being developed by A, and it took a lot of time.

So what happened?

• A worked the whole night to complete feature alpha.

• Meanwhile B had to stop feature beta and wait the whole night because alpha wasn’t ready.

Finally:

• A completed feature alpha,

• pasted it into the pen-drive,

• and handed it to B so that B could complete beta and paste the code too.

But when A came to B, he realized:

😩 B couldn’t write feature beta at all because it was heavily dependent on feature alpha’s code.

Because of this delay:

• they couldn’t ship the features by morning and lost the client

6. What This Pen-drive Tracking Software Solved

After this, B carried on implementing feature beta. Later, feature gamma and feature pie were also added by Person A and B into the existing code.

Now they could clearly see:

• which lines of code in a feature were written by A

• which lines were written by B

• the date and time when it was written

• which deletions were done, and by whom

This improved their ability to code and ship because:

• they could track who wrote the code

• what purpose it was written for

• what was changed and why

• what buggy code was removed so it doesn’t get replicated again

So this solution did solve tracking and logs, and reduced the out-of-sync issue.

But it still couldn’t solve a bigger issue.

7. Where It Lacked: Live Collaboration Problem

Even though tracking improved, there was still one major bottleneck:

Only one person could edit at a time

So NO parallel work could be done properly.

This meant collaboration was still broken, and teams couldn’t work efficiently on inter-dependent code.

To solve this collaboration problem, the next invention was introduced…

8. Version Control Systems (VCS)

To solve the live collaboration issue, we moved from pen-drive based tracking to a server based architecture that not only tracks BUT also supports live collaboration and sync of folders.

8.1 Some popular VCS are:

➤ Git
➤ Mercurial
➤ Subversion
➤ Bazaar

Now, instead of keeping the code inside a pen-drive, we deployed our software to a server.

So:

• any new code update / deletion done by Person A

• becomes visible to Person B live

• because all the changes, updates, and deletions are getting tracked on a live server

• and that server is also connected to Person B’s system

Hence, Person B instantly sees the changes made by Person A due to the deployment of the VCS on the server.

9 . NOTE

9.1 The software we have been mentioning all the way along is called Version Control Systems (VCS)

Most popular among the VCS is Git (released in 2005).

And when this software (in this case Git) is deployed on a server, it becomes a VCS remote.

Some popular VCS remote are:

➤ Github

➤ Gitlab

➤ BitBucket

➤ AWS CodeCommit

9.2 So basically:

Git is a Version Control System
and when it gets deployed, it becomes a VCS remote, with Github being the most popular VCS remote.

10 . Conclusion (The Final Line 😉)

So:

Git = VCS

Github = VCS remote

That is why we always study about Git and never about Github 😅

Next time someone says “I am learning Github”…
you know what to tell that person.