Teamwork#
Code written alone differs from code written in a team. Working in a team brings shared ownership, inherited conventions, parallel branches, code review, and release cycles. The Software Development Life Cycle (SDLC) is the unifying framework for contributing to a codebase in teams.
SDLC is the loop a team applies to its codebase from start to finish. It runs through eight phases.
Phase |
What happens |
|---|---|
Plan |
Pick what to build. Requirements, scope, milestones, prioritisation. |
Design |
Decide how to build it. Architecture, interfaces, data model, sequence diagrams. |
Build |
Write the code. Branches, feature flags, unit tests alongside the implementation. |
Review |
Have someone else read the change. Pull requests, code review, security review, ADR sign-off. |
Test |
Verify the change against the contract. Unit, integration, e2e, performance, security tests. |
Ship |
Get the change in front of users. Merge, build, release, deploy, canary, rollout. |
Run |
Operate it in production. Monitoring, on-call, incident response, support. |
Retire |
Take it out of service. Deprecate, migrate users, sunset, archive. |
How the team structures work over time. Waterfall, agile, Scrum, Kanban, continuous delivery, trunk-based.
The SDLC phases the team moves work through. Vocabulary that survives any methodology.
Day-to-day habits that distinguish high-performing teams. Code review, pairing, stand-ups, retros, ADRs.
Changing the structure of code without changing behavior. The team’s mechanism for keeping the codebase liveable.
The team’s contract with itself. Unit, integration, e2e, property-based, smoke; pick the right tests for the right tiers.
Planning, tracking, designing, communicating. The team-scale tooling around the code itself.