How Software Is Actually Built in Companies

Main Ideas / Concepts Covered

• Goal of the video: Explain how software is built in real company teams—from turning an idea into requirements, dividing work across roles, implementing features, using version control, deploying, and running multi-stage testing.

Team Structure (Roles and Responsibilities)

• Product Manager (PM):

  • Owns product outcomes, deadlines, delivery dates, and business goals
  • Translates client/user feedback into requirements

• UI/UX Designer:

  • Creates prototypes/designs (layout, placement, logos, UI structure) before development
  • Uses feedback to refine designs

• Scrum Master / Tech Operations & Scrum Master (SM):

  • Breaks PM “stories” / requirements into smaller tickets appropriate for sprints
  • Assigns and coordinates workflow and priorities

• Team Lead (TL) (sometimes called principal architect):

  • Handles system/architecture design and has code review authority
  • Assigns tickets to developers
  • Ensures quality, optimization, and correctness

• Developers (often full-stack/mixed-role in the example):

  • Implement features (UI integration, backend logic, and deployment knowledge)

Work Division Across Front-End and Back-End

• Roles can be specialized (e.g., SEO, animations, integration teams).
• Companies may split responsibilities between front-end and back-end accordingly.

Agile / Sprint Workflow

• Work is delivered in time-boxed iterations (sprints), commonly about a week (but variable).

Feedback Loop Drives Requirements

• Client feedback + user behavior feedback (e.g., from monitoring tools) influences what gets built next.

Monitoring / User Behavior Tools Mentioned

• Microsoft Clarity (and similar tools): tracks user interactions like mouse events, clicks, and attention to refine the product experience.

---

End-to-End Methodology (Process Flow, Step-by-Step)

1) Start from an Idea → Capture Requirements (“Story”)

• A hypothetical example is given: tracking student progress
  • Study progress, performance, and identifying top performers for opportunities
• PM gathers requirements from:
  • Direct client requests
  • User feedback (including behavioral signals)
• The output is treated as a “story” (also described as similar to requirements or an SRS-like document).

2) PM → SM: Break Story into Tickets for Sprints

• SM divides the story into smaller implementation tasks, such as:
  • Database design / architecture planning
  • Infrastructure choices (e.g., AWS services/machines)
  • Front-end UI integration into development
• SM creates multiple tickets derived from the story/feature and sets their priority (conceptually: severe/medium/low).

3) Tickets → TL: Assign Work and Design the Solution

• Tickets are not automatically self-claimed by developers.
• TL receives tickets from SM, then:
  • Assigns tasks to specific developers
  • Leads or performs architecture/system design
  • Reduces developer cognitive load by making key design decisions upfront

4) Developers Implement Feature Work in Branches

• Developers use version control (Git; referenced example: GitHub/Gate Hub).
• For each feature:
  • They create/push code to a feature branch
  • Push updates to relevant repositories (front-end and back-end may be separate)
• TL performs code review on the feature branch.
• For approved feature branches:
  • A Pull Request (PR) is created toward the main branch
  • Main branch access is restricted (developers generally can’t push directly; TL/higher manages merges)

5) PR Review Visibility + Synchronization

• Once PRs are raised, the whole team can view what’s being built and by whom (for coordination and knowledge sharing).
• TL’s PR approval includes quality checks and verification that tests pass.

6) Main Branch → CI/CD (“GitHub Actions”) → Deploy

• After PR merge into main, CI/CD runs automatically.
• CI/CD pipeline purpose:
  • Re-run test suites defined in the pipeline (e.g., linting, prettier, code-quality tests)
  • Promote merged code into the main environment (i.e., what users access)
• CI/CD ownership is attributed conceptually to TL / higher authority roles (as described in the video).

7) QA Role and Staging/Testing Environments (Dev vs Staging vs Test-like)

• In the described “real flow,” code is not pushed directly to production without intermediate environments.
• Environments include:
  • Dev environment (developer/local; in large companies also shared)
  • Stage / testing environment
  • Main / production environment
• Databases vary per environment:
  • Dev uses junk/test data
  • Testing uses test data

Promotion Flow Between Environments (as described)

• Feature branch → merge into dev
• Dev merge → forwarded to test/staging
• Testing PR → QA checks, runs tests, then approves merging forward

8) QA Testing Types (Detailed)

• Smoke testing:

  • Quick verification that the feature works end-to-end at a basic level
  • Not focused deeply on internal performance/optimization
  • Example: “click the button and verify it works”

• Pilot testing (beta-like):

  • Release to a small group of users to observe real usage feedback

• QA test cases / TDD-style testing:

  • QA may write test cases first
  • Developers implement code to pass those test cases (referenced as TD/Test-Dev idea)

• Load testing:

  • Tests under high traffic / many concurrent users

• Multiple rounds of testing + bug fixing:

  • If tests fail (smoke/load/test cases), QA flags failure and the work returns for fixes
  • After fixes, the PR/branch is retested and re-approved

9) Promotion Gates and Approvals (Who Can Approve)

• After staging/testing approval:
  • PM may also verify expectations are met
  • Higher management (e.g., roles referred to as HOT / CD / SD3-like) can approve for merging
  • TL may merge if higher approvers aren’t available and QA review passed
• If approved:
  • PR merges into main
  • Users see the new feature

10) Hot Fix Branch for Urgent Production Issues

• Severity concept: if the bug is extremely severe (P1-like), use a hot fix path.
• Hot Fix flow (more direct, less testing):
  • Create a hot fix branch
  • Urgently merge into main (or directly with privileged access)
  • TL / higher authority reviews quickly
  • “No full testing” is described for emergencies to restore service fast
• Example analogy given: a service outage like “Instagram is down.”

---

Lessons / Takeaways Emphasized

• Software building is a pipeline of responsibilities, not “everyone codes everything.”
• PM-user feedback drives what gets built—not assumptions.
• Work division is intentional:
  • PM defines outcomes
  • UI/UX designs the interface
  • SM organizes sprint tickets
  • TL owns architecture + quality gates
  • Developers implement
  • QA validates using multiple test types
• Version control and CI/CD are central for safe integration and automated deployment.
• Staging/testing reduces risk; production changes are promoted only after QA/approvals.
• Emergency changes use a hot-fix path when the normal workflow is too slow.

---

Speakers / Sources Featured

• Sarthak Sharma: host/questioner (intro/outro; sets context and asks questions)
• Harsh Patel: head of tech (main interviewee; explains team/software process)
• Sherians Scoring School: channel/brand referenced in the video
• Coder Boot Camp: referenced as an associated training/community
• Microsoft Clarity: example tool for user behavior/monitoring