Software Development Lifecycle¶

The bar: you can take a feature from a one-line request to a planned, documented, reviewed, and shipped change — and explain every decision you made along the way.

Writing code is the loud part of the job. It is not the whole job. The engineers who get trusted with real work are the ones who know what happens before the first line and after the last one: how a vague request becomes a clear plan, how a plan becomes a design, how a design gets built in small reviewed pieces, and how the whole thing stays documented so the next person isn't lost.

This module walks the lifecycle end to end. You are learning the same rhythm a team uses to ship software that thousands of veterans actually depend on. Master it and you stop being someone who can code — you become someone a team can hand a problem to and trust to bring it home.

7.1 Requirements and Planning¶

Objective: gather and document requirements so the thing you build is the thing that was actually needed.

Most wasted engineering effort traces back to a fuzzy start. Somebody said "add profiles" and everybody imagined something different. The fix is a user story: a short statement in the form As a [role], I want [action], so that [benefit], paired with acceptance criteria — the concrete, checkable conditions that mean "done." When you can't write the acceptance criteria, you don't understand the request yet.

Big requests are epics. You decompose an epic into stories small enough to finish in a day or two. Then you prioritize, because you can never do everything at once. MoSCoW — Must, Should, Could, Won't — forces stakeholders to say out loud what actually matters this round. That conversation is stakeholder communication, and it is where you defend the MVP: the smallest version that delivers real value. The classic self-taught mistake is silent scope creep — building the "Could haves" nobody asked for while the "Must haves" slip.

Drill:

• Write a user story in the As a / I want / so that form with 3+ acceptance criteria.
• Break one epic into 4-6 stories, each independently shippable.
• Rank a backlog with MoSCoW and defend the cut line to a stakeholder.
• Write a one-paragraph MVP definition that names what is explicitly out of scope.

7.2 Design and Architecture¶

Objective: design the system on paper before you commit it to code.

Ten minutes of design saves hours of rework. Before building, sketch a system architecture diagram showing the major pieces and how data flows between them. Then do component design — deciding what each part is responsible for and where the boundaries sit — so responsibilities don't bleed together.

Two contracts deserve special care. API contract design locks down request and response shapes so front end and back end can build in parallel without guessing. Database schema design decides your tables, columns, and relationships up front, because migrations against live data are the expensive kind of mistake. Get these wrong and every downstream decision inherits the flaw.

Finally, write down why. An Architecture Decision Record (ADR) is a short doc capturing a decision, the alternatives you weighed, and the tradeoff you accepted. Six months later, when someone asks "why Postgres and not a document store," the ADR answers instead of a shrug. That is design documentation doing its job: recording intent, not just structure.

Drill:

• Diagram a feature's architecture (boxes for services, arrows for data flow).
• Write an API contract: endpoint, method, request body, response shape, error cases.
• Model a database schema — tables, columns, keys, relationships.
• Write one ADR with Context, Decision, and Consequences sections.

7.3 Agile and Kanban¶

Objective: work effectively inside the cadence real teams use.

Agile is a mindset from the Agile Manifesto: ship working software in small increments, respond to change, keep humans talking. Two frameworks put it into practice. Scrum organizes work into fixed-length sprints with defined roles (product owner, scrum master, developers) and ceremonies — sprint planning, daily standup, review, retrospective. Kanban is lighter: a board of columns from To Do to Done, with WIP limits that cap how much can be in progress at once so work actually finishes instead of piling up half-done.

Sprint planning and estimation is where the team commits to what fits, usually sizing stories in relative points rather than hours. The daily standup is a 15-minute sync — what you did, what's next, what's blocking you — not a status report to a manager. Retrospectives are where the team improves its own process honestly.

You track progress with velocity (points completed per sprint, which makes future planning realistic) and burndown charts (work remaining over time). The rookie error is treating standup as theater and retros as optional. The teams that improve are the ones that use them for real.

Drill:

• Run a mock standup answering the three questions in under two minutes.
• Estimate a set of stories in relative points and explain your reasoning.
• Set up a Kanban board with a WIP limit on the in-progress column.
• Read a burndown chart and say whether the sprint is on track.

7.4 Technical Documentation¶

Objective: write documentation people actually read.

Docs fail when they're written for no one. A good README is the front door: what the project is, how to run it, how to contribute — enough that a new engineer is productive without asking. API documentation tells consumers what each endpoint takes and returns. Neither should make the reader guess.

Code comments explain why, not what — the code already says what it does; the comment captures the reasoning the code can't. Architecture documentation keeps the big-picture map current so the system stays understandable as it grows. Runbooks and playbooks are the operational docs: step-by-step procedures for when something breaks at 2 a.m. and you need to act, not think.

The unifying idea is documentation as code — docs live in the repo next to what they describe, get reviewed in the same pull requests, and stay in version control. Docs in a forgotten wiki rot; docs beside the code get updated when the code does.

Drill:

• Write a README with sections: what, install, run, contribute.
• Document one API endpoint with request, response, and error examples.
• Add a "why" comment to a piece of non-obvious code and delete a redundant "what" comment.
• Draft a runbook for one recurring operational task.

7.5 Code Review¶

Objective: give and receive code reviews that make the code and the team better.

Code review is quality control and knowledge-sharing at once. As a reviewer, look for correctness, clarity, edge cases, and unnecessary complexity — not personal style preferences. As an author, make your pull request reviewable: keep it small and focused, write a description that explains the change and why, and never drop a thousand-line PR on a teammate and expect a real review.

Feedback is a skill. Constructive feedback targets the code, not the person, explains the reasoning, and distinguishes blocking concerns from suggestions. "This will break on empty input" helps; "this is wrong" doesn't. Receiving it well — assuming good intent, asking questions instead of defending — is just as important.

Run automated checks before review so humans aren't wasting attention on things a machine catches. Formatting, linting, type errors, and failing tests should all be caught by CI before a reviewer looks. And respect turnaround time: a PR sitting for three days blocks a teammate. Fast, focused reviews keep the whole team moving.

Drill:

• Open a PR under ~400 lines with a description covering what and why.
• Leave three review comments: one blocking, one suggestion, one question.
• Rewrite a blunt comment into constructive feedback.
• Verify lint, format, types, and tests pass locally before requesting review.

Hands-On Lab: Project Kickoff¶

Objective: run a complete project planning process end to end, from requirements to review.