Software Teams and Roles
Before you start
You need: nothing at all. This is the first article of the first foundation track, and it assumes no technical background.
Time: about 40 minutes.
New to all of this? Start here explains what an application is made of and introduces the school system every example uses. Any word you do not recognise is in the glossary.
Learning objective
Name the roles on a software team, say what each is responsible for, and know who to ask when you are stuck.
Topics
- What software development actually is
- Kinds of software
- Who asks for the software
- Product and delivery roles
- Developer specialisations
- The meetings you will attend
- How work reaches you
- Communication habits that mark out a good fresher
What software development actually is
Most of a developer's week is not typing code.
| Activity | Roughly |
|---|---|
| Understanding what is needed | A quarter |
| Reading existing code | A quarter |
| Writing new code | A fifth |
| Testing and fixing | A fifth |
| Meetings and coordination | The rest |
Reading and understanding outweigh writing. A fresher who expects to spend the day producing code is surprised by this; one who expects it is not.
The reason is that software is changed far more often than it is created. NexCoding Academy's school portal was written once and has been modified every week since. Every change starts by reading what is already there.
Kinds of software
| Kind | Runs | Example |
|---|---|---|
| Web application | In a browser | The school portal's student list |
| Web API | On a server, no interface | The service the portal calls for data |
| Desktop application | On a machine | The old fee-counter software |
| Mobile application | On a phone | The parent app showing attendance |
| Background service | On a schedule, unattended | The nightly fee-reminder job |
The tracks that follow build the first two. A school portal in the browser, an API behind it, a SQL Server database behind that. Track 04 covers reading the desktop and Web Forms systems many companies still run.
Who asks for the software
Software exists because someone has a problem. In the School Management System, the requests come from people with jobs to do:
| Person | Wants | Because |
|---|---|---|
| Principal | A class-wise result report | To review performance before parents' day |
| Office staff | Search students by roll number | Scrolling 800 students to find one wastes ten minutes |
| Accounts clerk | A list of fee defaulters | Manual reconciliation in Excel takes two days |
| Class teacher | Mark attendance from a phone | The register goes back to the office each period |
| Parent | See marks without visiting | The school is 20 km away |
None of them describe a solution. They describe a problem. "I need a report" is the shape of the request; deciding what the report contains, where it lives and how it is produced is the team's work.
A developer who understands the problem writes better software than one who only has the specification. Asking the accounts clerk what they currently do in Excel is often more useful than reading three pages of requirements.
Product and delivery roles
| Role | Responsible for | Ask them about |
|---|---|---|
| Business Analyst (BA) | Turning a request into clear requirements | What is actually needed, and why |
| Product Owner / Manager | Deciding what gets built and in what order | Priority, scope, whether something is in this release |
| Project Manager | Timelines, dependencies, reporting | Deadlines, who is blocked, status |
| Scrum Master | Removing obstacles, running the process | Anything blocking you that you cannot unblock |
| Team Lead / Tech Lead | Technical decisions, code quality, mentoring | How to approach a problem; code review |
| Architect | System-wide structure and standards | Cross-cutting technical decisions |
| QA Engineer | Verifying the software behaves as agreed | What they will test; why a defect was raised |
| DevOps Engineer | Build pipelines, deployment, environments | Why the build failed; how to get to the QA environment |
| Support Engineer | Production issues reported by users | What users are actually hitting |
On a small team one person holds several of these. A ten-person company may have one lead who is also the architect and the DevOps engineer. The responsibilities still exist; they are just concentrated.
The BA and the QA engineer are the two most useful people to a fresher. The BA knows what the software should do; the QA engineer knows what it currently does. Between them they answer most questions faster than reading code.
Developer specialisations
| Specialisation | Works on | In this curriculum |
|---|---|---|
| Frontend | What the user sees and clicks | Tracks 09, 11, 12 |
| Backend | Business logic, APIs, integrations | Tracks 03, 07, 10 |
| Database | Schema design, queries, procedures | Tracks 06, 07, 08 |
| Full stack | All of the above, to a working level | The whole guided path |
| Mobile | Phone applications | Not covered here |
"Full stack" means competent across the layers, not expert in all of them. A full-stack fresher can build a student list end to end — React page, API endpoint, SQL query — and knows when to ask a specialist.
Choose a depth and keep breadth. Being the person who understands the fee module completely is more valuable than being vaguely aware of everything.
The meetings you will attend
| Meeting | When | Your part |
|---|---|---|
| Daily stand-up | Every morning, 15 minutes | What you did, what you will do, what is blocking you |
| Sprint planning | Start of each sprint | Estimating and understanding the work you are taking |
| Sprint review / demo | End of each sprint | Showing what you built, to the people who asked for it |
| Retrospective | End of each sprint | What went well, what did not, what to change |
| Backlog grooming | Mid-sprint | Clarifying upcoming work before it is planned |
| Code review | Continuously | Reading colleagues' changes; responding to theirs on yours |
A sprint is a fixed period — usually two weeks — in which the team commits to a set of work. At the end, whatever is finished is demonstrated, and the next sprint is planned. The word appears in every stand-up you will attend.
Stand-up is not a status report to a manager. It is the team synchronising. Three sentences:
Yesterday: finished the student search endpoint, raised the PR.
Today: starting the fee defaulter query.
Blocked: need the QA database refreshed — the fee data there is from March.
Say you are blocked on the day you are blocked. A fresher who spends three days stuck silently has cost the team three days; one who says so on day one costs ten minutes.
How work reaches you
Work arrives as an item on a board — Jira, Azure DevOps, GitHub Issues or a similar tool.
NCA-142 Add student search by roll number
Type: Story
Status: Ready for development
Sprint: Sprint 14
Assignee: Ravi Kumar
Estimate: 3 points
Description
Office staff currently scroll through 800 students to find one.
They need to search by name or roll number from the students page.
Acceptance criteria
- Searching a full roll number returns exactly that student
- Searching a partial name returns all matching active students
- Searching something with no match shows "No students found"
- Only students of the signed-in user's school are returned
| Field | Means |
|---|---|
| Type | Story (new capability), Bug (something broken), Task (technical work) |
| Status | Where it is — To Do, In Progress, In Review, In QA, Done |
| Sprint | Which two-week block it belongs to |
| Estimate | Relative effort, usually in points rather than hours |
| Acceptance criteria | What must be true for this to be finished |
The acceptance criteria are the definition of done. If a criterion is unclear, ask before you start — not after you have built the wrong thing.
The last criterion in that example is the kind freshers skip: only the signed-in user's school. It is a security rule disguised as a filter, and Track 10 shows what happens when it is missed.
Communication habits
Four habits that separate a fresher people want to work with from one they do not.
Ask early, with what you have already tried.
Bad: "The fee page isn't working."
Good: "The fee summary shows ₹0 for Ravi Kumar (NCA-2024-0012), who has
paid ₹12,000. The API returns paidAmount: 0. I checked the database
and there are two FeeAccount rows for him — 2023-24 and 2024-25.
I think the query is picking the wrong one. Am I on the right track?"
The second takes two minutes to answer. The first takes twenty.
Say what you do not know. "I have not used Dapper before, can you point me at an example in this codebase?" is fine on day three and fine in year three. Pretending is what causes damage.
Give estimates as ranges, and update them. "Two to three days, and I will tell you tomorrow if it looks longer" is honest and useful. A confident "one day" that becomes four is what erodes trust.
Write things down. A decision agreed verbally and never recorded is a decision that will be re-litigated in six weeks. Put it in the work item.
Where this goes wrong
| The mistake | What it looks like | Instead |
|---|---|---|
| Waiting to be told | Sitting blocked for three days because nobody asked | Say you are blocked the day it happens |
| Asking with no context | "The fee page isn't working" | Steps, expected, actual, what you already tried |
| Treating stand-up as a report | Speaking to the manager, not the team | Three sentences: did, doing, blocked |
| Guessing a requirement | Building the wrong thing carefully | Ask the BA — ten minutes now, three days saved |
| Confident estimates | "One day" that becomes four | Give a range and update it |
| Not recording a decision | The same argument again in six weeks | Put it in the work item |
Nobody is annoyed by a fresher asking a good question. They are annoyed by a fresher who was stuck for three days and said nothing.
Common mistakes
- Expecting to spend the day writing code
- Staying silent when blocked
- Starting work before the acceptance criteria are clear
- Treating stand-up as a report to a manager
- Guessing at a requirement rather than asking the BA
- Giving a confident estimate to avoid looking slow
- Never talking to QA until a defect is raised
- Assuming "full stack" means expert everywhere
- Not recording a decision made in conversation
Practice
The course exercise is identify roles in a sample project.
- List every role above and write one sentence on what each is responsible for, without looking.
- For each of the five School requesters, write the problem they have — not the feature they want.
- Take the NCA-142 work item and identify who wrote each part: description, acceptance criteria, estimate.
- Write three stand-up updates for yourself — one where you are progressing, one where you are blocked, one where you finished early.
- Rewrite "the fee page isn't working" as a report someone can act on.
- For a feature you would build — a fee defaulter report — list which role you would ask each of these: what counts as a defaulter, when it must ship, how it will be tested, which environment to test in.
- Find out which board tool your college or company uses, and open one real work item.
- Identify which developer specialisation you are drawn to, and which of these tracks builds it.
- Write down three things you do not know yet, in the form you would use to ask a lead.
- Attend or watch a stand-up. Note how long each person speaks.
Exercise 5 is the one that pays off in your first week.
You can now
- Name the roles on a software team and say what each is responsible for
- Say what a sprint is and what happens at the end of one
- Describe how a work item reaches you and what its fields mean
- Give a stand-up update in three sentences
- Ask a question in a form someone can answer in two minutes
- Say who to ask what a feature should do, and who to ask what it does now
Review questions
- Why do reading and understanding take more of a developer's week than writing code?
- What is a sprint, and what happens at the end of one?
- Who would you ask what a feature should do, and who would you ask what it currently does?
- What makes "the fee page isn't working" a poor question, and what would you send instead?