Write the plan before the code
Plan → specify → design → build → test
The software development life cycle is how a team builds, tests, and releases software that still works for someone else. Planning checks the goal, the cost, and whether the project is realistic. Requirements put the rules and the user needs in writing. Design is the architecture, the data, and the screens. Development is the code. Testing is where the bugs get found and fixed. Security sits in that same order: in design, write who can reach the data and how it can be abused; in test, those checks have to fail the build. Put what “done” means on paper while the plan is still cheap to change. The release window, the proof, and the cutover live on the Delivery card.
PLANGoal, cost, and a realistic yes or noSPECRules and user needs, in writingDESIGNArchitecture, data, screens, and who can reach themBUILDThe codeTESTBugs and security holes, found and fixedProblem → use → example
| If the real problem is… | Use | Example case |
|---|---|---|
| “Build the thing” with no acceptance | Written plan | Credit-engine rule change: who, which products, what “done” looks like — not a two-line chat ticket |
| Security shows up after the demo | Threat model in design | New partner API: data class, auth, and abuse cases written before the first commit — SDL practice, not a retro finding |
| Secure practices live in a binder, not the loop | SSDF in the SDLC | Review, tests, and supply-chain checks happen before merge; a phase diagram does not make the software secure |
| Nobody can tell if the change is safe to merge | Test pyramid | Unit on the scoring function, contract on the engine API, one path through the UI — not a week of manual clicking |
| Main is a graveyard of long-lived branches | Small batches on trunk | Incomplete UI behind a flag; main stays releasable — same CD test the Delivery card uses at cutover |
| Review is a rubber stamp after the fact | Review before merge | The pull request names the plan and the test. A Copilot draft is a draft; a person still owns the merge |
| “It works on my machine” is the evidence | CI on every change | Push to main runs tests and lint; broken trunk is the incident, not a Friday surprise |
| Don’t know what “secure enough” means for this app | ASVS level | Consumer-finance API: pick a verification level and fail the build on the controls that matter — not a 400-row audit dump |
| Dependencies are a mystery zip | Known supply chain | Lockfile + advisory scan on the credit-engine client; a new package is a change, not a convenience |
| Meetings replaced the written plan | Lead time | Time from the written plan to a change you can merge. A filled Scrum board doesn’t show the software is safer |
| Skip the tests so the change ships sooner | Small tested changes | Smaller changes with tests in the loop ship more often and fail less often. Skipping the test does not buy the speed. How often a change reaches production, and how fast you recover, sit on the Delivery card |
Default order: name the plan and the owner → write the requirements → design the system, including how it can fail → smallest build → test (bugs, review, security) → then the Delivery card for the window and the cutover.
Tool picker
What has to be written down
Ladder + gates
- Named plan and owner
- Design the system, who can reach the data, and how it can be abused
- Smallest build on trunk / flag
- Tests that fail for the right reason
- Review + security checks
- Mergeable — then Delivery for cutover
Anti-patterns
- Code before the requirements exist
- Security as a late finding
- Meetings with nothing written down
- Long-lived branches instead of flags
- “Works on my machine” as evidence
- Rubber-stamp review after merge
- Picking a framework before the plan exists
- Calling it shipped — that’s the Delivery card