Skip to main content

A 6-Week Capstone Schedule: Anti-Patterns and Recovery Moves

What This Concept Is​

A capstone schedule is a week-by-week plan that allocates the six weeks across framing, implementation, deployment, operational hardening, portfolio, and defense. The schedule is written in week 1 and then either respected or explicitly renegotiated -- never ignored. A schedule you wrote once and then stopped checking is not a plan; it is a wish.

The baseline plan for this capstone follows the semester outline:

WeekThemeGates / Artifacts
91Framing & architecture (this module)Design doc + 3 ADRs + C4 + risk register + 1 fitness function passing
92Implementation & testing (Module 2)Vertical slice deployed to staging; unit + integration tests green
93Cloud deployment & CI/CD (Module 3)CI green; deploy pipeline; rollback rehearsed at least once
94Operational readiness + security (Module 4)SLO draft; runbook; threat model; dependency audit
95Portfolio packaging (Module 5)Case study; screenshots; narrative; diagrams cleaned
96Final verification & defenseExam; 5-minute architecture defense; walkthrough

The schedule's purpose is not to enforce heroic productivity -- it is to make slippage visible early. Every Friday you compare what the plan predicted to what you actually produced, and you act on the delta. The earlier the delta is detected, the cheaper the recovery move.

Anti-patterns are the predictable ways this plan fails in practice. Each has a named detection signal and a named recovery move. Anti-patterns are not character flaws; they are attractors -- gravity wells any solo learner will drift toward. Knowing their names lets you notice the drift.

Recovery moves are things you do -- pre-committed, written down -- when (not if) an anti-pattern triggers. They are scripts, not improvisations. In crisis, you do not improvise a plan; you execute a pre-chosen one.

Why It Matters Here (In the Capstone)​

Capstones do not fail because the schedule was unrealistic. They fail because nobody noticed it was slipping until week 5, when there is no time left to recover. Writing down the schedule and the recovery moves in week 1 creates a cheap weekly feedback loop that replaces the expensive late-week panic loop. Two days slippage in week 2 costs a scope cut; two days slippage in week 5 costs the whole defense.

The second reason the capstone needs this specifically: you are solo. There is no peer, no standup, no manager whose discomfort alerts you to drift. Your Friday review with yourself is the only early-warning signal you have. If you do not schedule it, there is no signal, only symptoms that arrive when they are already terminal.

The third reason: a defensible capstone is one that shipped* and then discussed how shipping went -- including what was cut and why. A capstone that pretended everything went to plan does not read as engineering maturity; it reads as dishonest. The schedule with tracked deltas is the record you use in the defense to describe your own engineering honestly.

Concrete Example(s) -- from a real capstone​

Example A -- named anti-patterns with real capstone detection signals and recovery moves:

  • Anti-pattern 1 -- Big-Up-Front-Design Trap. You spend weeks 1-2 on the design doc because it is rewarding and zero-risk. End of week 1: design doc is 12 pages, no code beyond scaffolding. Recovery: declare design-doc v0.9, move on. The doc will keep evolving; it is never "done." See concept 10.
  • Anti-pattern 2 -- Horizontal Building. Week 2 you build "the UI," week 3 "the API," week 4 "the DB." End-to-end never ran until week 5, when the schema disagrees with the API shape. Detection: end of week 2, no request has ever crossed all layers on staging. Recovery: drop everything; build the MVP vertical slice (concept 03) before adding any horizontal layer.
  • Anti-pattern 3 -- Shiny Stack Detour. Week 3 you discover Rust / Elixir / Bun / a new framework and decide to migrate. Detection: you find yourself reading intro docs instead of solving a specific problem. Recovery: write an ADR for the migration first; if you cannot cite a top-3 driver that forces it, revert the branch.
  • Anti-pattern 4 -- Infrastructure Sinkhole. Week 3-4, you are deep in Kubernetes, service mesh, OpenTelemetry collectors. Detection: two consecutive weeks with no commits to src/core/. Recovery: set a one-week infra budget; simplest deployment wins. Single VM + managed Postgres beats EKS every capstone, every time.
  • Anti-pattern 5 -- Week-5 Panic. MVP still not deployed; you start cutting tests, skipping runbook, deploying via scp. Recovery: invoke scope-cut rules (concept 14). Cut features, never quality gates.
  • Anti-pattern 6 -- Defense Surprise. Week 6 arrives and you have never said the architecture out loud. Recovery: rehearse weekly from week 1, even with no code (concept 15).

Example B -- inventory capstone schedule with concrete weekly artifacts:

  • Week 91: design doc skeleton, ADR-001/002/003 drafts, C4 Context + Container, top-5 risks, scan-idempotency fitness function passing on a stub.
  • Week 92: vertical slice (scan -> persist -> on-hand query) deployed to Supabase staging; integration test for happy path green.
  • Week 93: GitHub Actions CI green; /health post-deploy check; manual rollback rehearsal (deliberate bad deploy + revert).
  • Week 94: SLO draft (scan p95 < 500ms, availability 99%); runbook for "DB connection exhausted"; dependency audit.
  • Week 95: portfolio case study; screenshots of scan UI; C4 diagrams polished.
  • Week 96: defense rehearsed; exam; live defense.

Example C -- ticketing capstone Friday review template:

Week 93 Friday review (2025-03-20)
- Plan: CI green, staging deploy pipeline, rollback rehearsed.
- Reality: CI green. Deploy pipeline 80% (no rollback step yet).
  Rollback un-rehearsed.
- Delta: 2 days behind on rollback.
- Move: invoke scope-cut rule #3 (drop "export ticket list to PDF").
  Use the two recovered days to finish rollback and rehearse.
- Risk register touched? No new rows.

The template is what makes the review real. Without a template, "Friday review" is wishful thinking.

Common Confusion / Misconceptions​

  • "Schedules are for teams, not solo work." Solo schedules are more important because there is nobody to notice slippage but you. Without the schedule, there is no "behind."
  • "If I am slipping, I'll just work harder." You will not -- and if you do, you will burn out in week 4. Slippage is resolved by cutting scope or shifting plan, not by promising to sleep less.
  • "I can skip the Friday review when I'm not slipping." That is exactly when you must run it -- to confirm you are not slipping. A review you only do in crisis is a panic log, not a plan.
  • "Rehearsing the defense in week 1 is premature." The rehearsal is a diagnostic, not a performance. Its job is to reveal holes in the design doc while there is still time to fix them.

How To Use It (In Your Capstone)​

  1. Copy the baseline table into your design doc's Schedule section on day 1 of week 1.
  2. For each week, attach 2-4 concrete artifacts with verifiable states ("pipeline green on main," "runbook under library/raw/runbook.md," "fitness function X passing in CI"). Vague weeks drift.
  3. Book a recurring 20-minute Friday review. Use the template from Example C: plan, reality, delta, move, risks touched.
  4. Set a slippage threshold up-front. Common rule: >2 days behind = invoke scope-cut rule (concept 14). No renegotiation.
  5. Rehearse the 5-minute defense every Friday, even when the system is incomplete. Use whatever exists.
  6. Name, out loud, which anti-pattern you fell into when a cut is triggered. The naming is half the recovery.
  7. Keep a weekly one-line journal. Future you, or a hiring manager, reading the capstone repo will find those journal lines more convincing than the final writeup.

See also (integrative)​

The schedule discipline is built on iteration-and-feedback from S8 M01 and the small-reversible-change ethos of S9 deployment.

External references (curation-validated this session):

Check Yourself​

  1. What are the two anti-patterns you are most likely to hit, and what is the detection signal for each?
  2. What does your Friday review produce, concretely?
  3. At end of week 2, you are two days behind. What is your exact next action?
  4. What gets cut first, according to your pre-committed list, before week 3 begins?
  5. Can you give a 5-minute defense today, with what currently exists?

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (20 min). Copy the baseline schedule into library/raw/design-doc.md. For each of the six weeks, write 2-4 concrete artifact gates (verifiable files, commits, or test runs).
  • Drill 2 (10 min). Write, beside the schedule, the two anti-patterns you are most likely to hit and their detection signals in your own words.
  • Drill 3 (5 min weekly). Paste the Friday review template into your journal. Fill it every Friday at 4pm. Non-negotiable.
  • Drill 4 (10 min, end of week 2). Run your first real Friday review. Observe how small the delta feels now vs. how it would feel discovered in week 5.
  • Drill 5 (5 min weekly). Give the 5-minute defense rehearsal out loud. Speaking reveals gaps that reading past.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.