Nobody writes a working app top to bottom in one go. Real software is built in loops and pieces — and usually by more than one person.
The CED’s take on how development and collaboration work. Enrolled in our Runestone course? Open it from there so your progress counts.
A step back inside Programs. You’ve been writing code; today is about the process around it — the part the Create PT actually grades, and the part that separates “I typed something” from “I built something.”
That’s liberating news for you: your first draft is supposed to be rough. The skill isn’t writing perfect code once — it’s having a process that turns a rough draft into a good program, reliably. Today you learn that process and the words the exam uses for it.
Software is built two ways at once, and the exam wants you to tell them apart:
| Approach | Means | Picture it |
|---|---|---|
| Iterative | repeat and refine the same part until it’s right | redrafting one paragraph over and over |
| Incremental | build in separate pieces, then combine them | writing chapters, then assembling the book |
They work together: you build one increment (a piece), then iterate on it until it’s solid, then add the next piece. Around the code sit two habits the CED names directly — investigating (before you build: who is this for, what exactly should it do?) and reflecting (after: what worked, what would you change?).
Investigating produces a program specification — a clear statement of what the program must do, agreed before coding. Your purpose sentence (2.5) is a tiny spec. Real projects have bigger ones, and skipping this step is how teams build the wrong thing beautifully.
Each scenario is one or the other. Refining the same piece is iterative; adding a new, separate piece is incremental. Decide, then check.
Five questions in AP format. Pick an answer for instant feedback.
A famous example: an early automatic soap dispenser worked for some people and not others — it failed to detect darker skin tones, because the team that built and tested it didn’t include anyone it would fail on. The code wasn’t “buggy” in the syntax sense. It ran perfectly. It was built and tested by too narrow a group to notice who it left out.
This is the CED’s point about collaboration, and it’s genuinely testable: diverse teams catch design flaws that homogeneous teams miss, because more kinds of people means more kinds of “wait, this breaks for me.” It’s the same “whose case did we forget?” question from the username lesson (2.7) — now applied to who’s in the room, not just what’s in the code.