Lab Design & Pedagogy¶
The CSE120 lab sequence didn't emerge fully formed. It evolved through multiple semesters of iteration, driven by a single question: how do you teach software engineering at scale without losing the individual student?
The Core Tension¶
Teaching software engineering to 114+ students per semester presents a fundamental tension:
- Team projects are essential — software engineering is collaborative by nature
- Individual accountability is hard — in a team of 4–5, individual contributions are easily masked
- Scale amplifies both — at 20+ teams, faculty can't directly observe every student's work
The lab sequence is designed to resolve this tension. Every design decision — from the order of labs to the grading formula to the Actionable Agenda — addresses one or more of these challenges.
The Lab Sequence: Why A→B→C→Scaffolding→Iterations?¶
The four-lab sequence follows a deliberate progression that mirrors how professional software projects actually unfold.
Labs 1-3: Design Before Build¶
Traditional capstone courses rush students into coding. CSE120 spends the first six weeks on design before any code is written:
| Lab | Focus | Pedagogical Goal |
|---|---|---|
| Lab 1: Team Formation | Team contracts, stakeholder discovery | Build social infrastructure before technical work — research shows that teams with explicit working agreements outperform those without |
| Lab 2: Requirements | Use cases, user stories, acceptance criteria | Force students to articulate what before how — the single most common failure in student projects is building the wrong thing correctly |
| Lab 3: Design | Wireframes, class diagrams, architecture | Make architectural decisions explicit and reviewable — wireframes exist to make mistakes cheap before implementation becomes expensive |
The three-week requirement analysis phase (Lab 2) is intentionally the longest design lab. Requirements engineering is the activity with the highest return on time investment in software projects, yet it's the one most frequently skipped by students who want to start coding.
Lab 4.0: Scaffolding as Gate¶
Lab 4.0 serves a critical gatekeeping function. Before teams can build features, they must: 1. Show they can ship — CI/CD pipeline passing, Docker configured 2. Show they can coordinate — Project Board populated with 80-100 issues 3. Show they have a plan — Milestones set for the full semester
This is the maturity test. Teams that can't set up infrastructure will not succeed at iteration. By requiring this as a separate graded checkpoint (50 points, individual peer evaluation), we catch struggling teams before they fall behind on feature work.
Labs 4.1-4.4: Progressive Scope¶
The four implementation iterations follow a scope-expansion pattern:
| Iteration | Scope Goal | Quality Focus |
|---|---|---|
| 4.1: Walking Skeleton | End-to-end steel thread | Architecture works, CI passes |
| 4.2: Core MVP | Highest-priority user stories | Integration testing, ADRs |
| 4.3: QA & Differentiation | Testing, UX, edge cases | Non-functional requirements |
| 4.4: Deployment & Release | Production-ready system | Full testing, documentation, handoff |
This pattern prevents two common failure modes: analysis paralysis (waiting too long to build anything) and big bang integration (building components that don't work together). The Walking Skeleton in 4.1 proves integration early; each subsequent iteration layers on functionality.
The Actionable Agenda¶
The Actionable Agenda lab format replaces the traditional "open work time" structure. Every minute has a documented purpose:
Stand-up (20 min)¶
Teams report blockers, share progress, and coordinate. This is not a status meeting — it's a coordination mechanism. The TA observes team dynamics, identifies struggling groups, and intervenes early.
Individual Demos (5 min/student)¶
Each student demonstrates their individual contributions to the TA. This is the highest-leverage 5 minutes in the course: - For students: Creates accountability — you must have something working to show - For TAs: Reveals contribution disparity — the student who "helped with testing" vs the one who built the API - For grading: Produces direct evidence for individual score adjustments
The individual demo is specifically designed to defeat the free rider problem in team projects. You can't hide in a team of five when you have to demonstrate your work one-on-one.
Workshop Time (remaining)¶
Hands-on work with TA triage. This is when students actually build things, with expert help available.
Flipped Pre-Requisite¶
Before each lab, students complete a "v0.1" task at home using provided Wiki guides. This ensures lab time is spent on meaningful work, not environment setup or basic tutorials.
Grading Design¶
The grading structure was designed to balance team incentives with individual accountability:
| Component | Weight | Design Rationale |
|---|---|---|
| Team score (base) | Variable | Incentivizes collaboration — everyone benefits from team success |
| Individual Multiplier | 40% TA / 50% Peer / 10% Self | Differentiates contributions within teams |
| 10% contribution threshold | — | Prevents penalizing students for minor peer friction |
| Quadratic penalty | — | Severe under-contribution accelerates penalties faster than minor issues |
The 10% threshold is a deliberate design choice: a student contributing 9% of the team's work (vs 11%) shouldn't face a drastic penalty, but a student at 2% should. The quadratic function creates a "cliff" that catches true free riders without punishing marginal contributors.
Changelog-Driven Reporting¶
Traditional lab reports encourage retroactive fabrication — students write about what they would have done. Changelogs with semantic versioning require: - Manual curation (no automation) - Categories: Added, Changed, Fixed - Correlation with merged PRs
This trains students to think critically about the nature of their contributions and creates a narrative git history.
Workshop Integration¶
Workshops are embedded in the course schedule at strategic points:
| Workshop | Placement | Purpose |
|---|---|---|
| GitHub Workshop | Before Lab 4.0 | Ensures all students can use the toolchain before they need it |
| Career Workshop | Week 4 | Early intervention — resume and professional presence before internship season |
| Communication Workshop | Week 14 | Addresses team friction that has accumulated by mid-semester |
The GitHub Workshop is specifically positioned as a prerequisite for Lab 4.0 — teams cannot begin scaffolding without completing it. This enforces baseline technical competence across all 114+ students.
The Generative Midterm¶
The midterm goes beyond traditional assessment. Each student receives a unique application concept with a randomized set of technical features — no two students solve the same problem. This design: - Eliminates the possibility of academic dishonesty - Tests adaptive problem-solving, not memorization - Produces a data-rich signal of individual understanding
Vector similarity matching flags submissions with >90% overlap, but the randomization makes true overlap vanishingly rare.
Continuous Evolution¶
This lab design is not static. Each semester produces data that informs the next iteration: - Score distributions reveal which labs are too easy or too hard - Peer evaluation patterns reveal team dynamics issues - TA feedback reveals which lab instructions are unclear
The current 26S design (described here) represents the culmination of multiple semesters of refinement, with each change grounded in data from the previous iteration.
Related Projects¶
- GradeFlow — Grading pipeline builder that will codify this lab sequence into reusable templates.
- T4 + TA Copilot — Task tracking for lab deliverables across the structured sequence.
- Psephos — Surveys instrumented throughout the lab to collect student feedback at each stage.