How Software Gets Built

#The Big Picture — From Idea to Live Product

Every expert was once a beginner. The people who built Instagram, Zomato, and ChatGPT once had no idea what a "sprint" or a "pull request" was either. You are learning the same playbook they use every single day. By the end of this lesson, you will be fluent in the language of software teams.

Someone in Bengaluru has an idea for an app that helps college students split hostel expenses. Six months later, it is on the Play Store with 50,000 downloads. What happened in between?

The journey from idea to live product follows a surprisingly consistent path, regardless of whether you are building a hostel expense app or a billion-dollar platform like Swiggy. Here are the stages:

1. Idea — Someone identifies a problem worth solving
2. Requirements — The team figures out exactly what to build (and what NOT to build)
3. Design — Architects plan the system; designers create the screens
4. Code — Developers write the actual software
5. Test — QA engineers verify it works and hunt for bugs
6. Deploy — The software goes live for real users
7. Maintain — Fix bugs, add features, keep it running

The big question is: in what order do you do these steps, and how rigidly do you follow them? That question is the entire reason software development methodologies exist.

#SDLC — Software Development Life Cycle

Let us walk through the three most important ones.

#Scrum Deep Dive — The Most Popular Method

Scrum is the most widely used Agile framework in the world. If you join a software team in Bengaluru, Hyderabad, Pune, or anywhere else, there is an extremely high chance they use some form of Scrum. Understanding it before your first day gives you a genuine advantage.

#The Scrum Team

A Scrum team is small — the 2020 Scrum Guide says typically 10 or fewer people in total. It has three roles:

#The Three Artifacts

#The Four Ceremonies

Scrum has four recurring meetings (called "ceremonies" or "events"):

The whole team meets. The Product Owner says "here are the most important items." The developers say "we can realistically finish these 8 items in 2 weeks." They discuss, negotiate, and agree a Sprint Goal plus a forecast of the items they expect to deliver. This is the plan for the next 2 weeks.

Forecast is the right word and it is worth getting right. The team commits to the goal, not to finishing every item on the list. Sprints where one item does not land are normal and are not a failure. A team punished for missing its forecast simply pads the next one, which makes every future plan less useful than the one before it.

The team stands up (literally, to keep it short) and each person answers three questions:

• What did I do yesterday?
• What will I do today?
• Is anything blocking me?

That is it. No problem-solving, no deep discussions. Those happen offline. The standup is a sync point, not a meeting.

The team demos what they built to stakeholders (the Product Owner, managers, sometimes actual users). "Here is the new checkout flow. Here is the search feature. Here is the bug fix for the payment timeout." Stakeholders give feedback, and that feedback goes into the Product Backlog for future sprints.

The team looks inward: What went well? What went badly? What should we change? This is how the team improves its own process. Maybe "our standups are running too long" or "we need better test data" or "pairing on complex tasks worked great, let us do more of that."

#A Typical Sprint

Here is what a 2-week sprint looks like in practice:

Then the cycle repeats. Every 2 weeks, the team delivers working software.

#Jira — Where Work Lives

Jira is the most popular project management tool in the software industry. Built by Atlassian (an Australian company), it is used by over 100,000 organizations worldwide. If you work in software, you will use Jira (or something very similar like Linear, Asana, or Plane).

#The Hierarchy of Work

Work in Jira is organized in a hierarchy:

The breakdown looks like this: one Epic contains many Stories. Each Story might have sub-Tasks. Bugs float around independently, filed whenever someone discovers a problem.

#Anatomy of a Jira Ticket

Every ticket in Jira has:

#The Board

The Jira board is the visual representation of work. Columns represent stages:

A developer's day revolves around this board. You grab a ticket from "To Do," move it to "In Progress" when you start, move it to "Code Review" when you open a Pull Request, and it moves to "Done" once it passes review and QA.

#Version Control — Git and GitHub

Imagine 10 people working on the same school project report in a shared Word document. One person edits the introduction while another deletes it. Someone copies the file to their desktop, makes changes, and emails it back with the filename "final_report_v3_FINAL_really_final_v2.docx." Chaos.

#Git — Save Points for Your Code

• Commit — Save a snapshot of your code at a specific moment. "Save point: added login page."
• Branch — Create a parallel universe where you can experiment without affecting the main code. If the experiment works, merge it back. If it does not, delete the branch. No harm done.
• Merge — Combine changes from one branch into another. "Take the login page from my branch and add it to the main project."
• Revert — Go back to any previous save point if something breaks. "The new payment feature caused a crash. Revert to yesterday's version."

Git is the default nearly everywhere, and it is the one to learn first. You will still meet exceptions: some very large companies run their own systems, and studios working with large binary assets such as game art often use Perforce, because Git handles big binaries badly. The concepts carry over, so learning Git is not wasted anywhere. It was created in 2005 by Linus Torvalds (the same person who created Linux).

#GitHub — Where the Code Lives Online

#Pull Requests — The Collaboration Ritual

Here is how a typical change flows in a real team:

1. A developer creates a branch (e.g., feat/password-reset)
2. They write code and make multiple commits on that branch
3. When the feature is ready, they open a Pull Request (PR) on GitHub — "Hey team, I built the password reset feature. Here are my changes. Please review."
4. Other developers review the code — they read through every change, leave comments, suggest improvements, catch bugs
5. Once approved, the PR gets merged into the main branch
6. The branch gets deleted (its job is done)

Pull Requests are where a huge amount of learning happens on real teams. Senior developers leave comments explaining why a certain approach is better, juniors ask questions, and everyone's code quality improves over time.

You do not need to master Git commands right now. Just understand the concept: Git lets multiple developers work on the same codebase without stepping on each other's toes, and Pull Requests are how changes get reviewed and approved.

Try simulating a basic Git workflow in code. This shows how commits build a history and branches let you work in parallel:

#CI/CD — From Code to Live Product

You have written your code and it has been reviewed and merged. Now what? How does it actually reach users?

#Continuous Integration (CI)

Every time a developer merges code, an automated system kicks in:

1. The code gets compiled (built)
2. Hundreds or thousands of automated tests run — unit tests, integration tests, end-to-end tests
3. Code quality checks run — linting, security scans, performance checks
4. If anything fails, the developer gets an alert: "Your code broke 3 tests. Fix it before merging."

This happens on every single code change, multiple times a day. The word "continuous" means it never stops running. The goal: catch bugs immediately, not 3 months later when the software is in production.

#Continuous Deployment (CD)

The difference is that one button. Delivery is far more common, and if you join a bank, an insurer or a medical device company, expect a named person to approve every production release, because the approval itself has to be recorded. No manual uploads. The pipeline handles everything.

The full flow looks like this:

Developer pushes code → Automated tests run → If all pass → Deploy to staging (internal testing) → Deploy to production (real users)

#Why This Matters for You

Even if you are building ML models, not web apps, CI/CD matters. When you train a model and want to deploy it as an API that an app can call, it goes through the same pipeline: automated tests verify the model works correctly, the API gets deployed to servers, and monitoring ensures it keeps working.

Understanding CI/CD is the difference between "I built a model in a Jupyter notebook" and "I shipped a model that 10,000 users rely on every day."

#What Day 1 At a Real Company Actually Feels Like

You've now read about sprints, Jira, Git, and CI/CD in theory. Here's what it actually feels like the first time. Most lessons skip this part. The first week is mostly emotional, not technical.

#Anatomy of a Code Review (What Your First PR Will Get)

Here's what real comments on a junior's PR look like, with the meta-translation underneath each:

"Consider extracting this into a separate function — it's getting hard to follow."

"What happens if user is null here?"

"Have you tested this with non-ASCII input?"

"There's a utility for this in utils/dates.ts."

"This works, but consider the performance implication with 10,000+ rows."

"LGTM" or "Approved"

#The Hidden Skill: Reading the Codebase

The single most underrated skill on a tech team isn't writing code. It's reading code. Senior engineers spend 4 hours reading for every 1 hour writing. Here is how to read a new codebase efficiently:

#Key Takeaways

• Software development follows a lifecycle: Idea → Requirements → Design → Code → Test → Deploy → Maintain. The methodology you choose determines how rigidly you follow these steps
• Waterfall is sequential and rigid (finish each phase before starting the next). Agile is iterative (build small pieces, get feedback, adapt). Kanban is continuous flow (no sprints, just a steady stream of work)
• Scrum is the most popular Agile framework: a small team works in 2-week sprints with four ceremonies (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective) to deliver working software every cycle
• Jira organizes work into Epics, Stories, Tasks, and Bugs — a developer's day revolves around picking up tickets, moving them through the board, and getting code reviewed
• Git tracks every change to code (commits, branches, merges) and GitHub hosts it online. Pull Requests are how teams review and approve changes
• CI/CD automates the journey from code to production — every change is automatically tested, and if all tests pass, it ships to users without manual intervention