AP Computer Science Principles · Unit 1
Unit 1 · Concept 3 of 5 · ~7 min read · 10–13% of AP exam
Build a small version, test it, improve it, and repeat. Iterative development is how real programs get made — and how AP CSP students build stronger Create Task projects.
Iterative development is the process of building a program in repeated cycles instead of trying to build the final version all at once. Each cycle adds or improves one feature, tests it, and uses what was learned to plan the next cycle. The result is a program that works at every stage and gets stronger with each iteration.
Iterative development is the practice of building a program in small, repeated cycles. Each cycle adds or improves one feature, then tests it before moving on. The opposite is building everything at once and testing only at the end — which usually produces more bugs and harder-to-fix problems.
Real programmers almost never sit down and write a finished program in one pass. They build a small working version, test it, fix what's broken, add one new feature, test again, and keep cycling. Each pass through the cycle is one iteration. The first version might only do one thing. The fifth version does five things — and each one was tested before the next was added.
Iterative development is a core idea in the program development process and connects directly to program testing. Without iteration, testing happens at the end and bugs compound. With iteration, every bug is caught while it's still small.
On the AP CSP exam, iterative development shows up as MCQs that ask "which action best shows iterative development?" or "what should the programmer do next?". The correct answer usually involves testing, refining, or returning to an earlier step with new information. On the Create Task, the students who score highest almost always built their program in at least 3 versions.
Iteration also pairs with collaboration in computing: partners can test each other's prototypes, compare notes after each cycle, and split work by feature so every iteration stays small. When you finish a cycle, you are ready for focused program testing on just the feature you added — not the whole program at once.
Official Big Idea 1 standards on College Board AP Central describe how computing innovations are developed through collaboration and iteration — each cycle should produce something you can run, test, and learn from before you add the next feature.
MCQs often contrast "build everything, then test once" with "build a small version, test, refine, repeat." The iterative path is almost always correct when the stem describes learning from test results or fixing one issue before adding the next feature. Written Create Task responses are stronger when you can name version 1, version 2, and what changed after each test.
One full iteration has 5 phases: plan a small change, build the simple version, test it, get feedback (from yourself or others), and refine based on what you learned. Then you start the next iteration.
| Phase | What you do | Example for a quiz app |
|---|---|---|
| 1. Plan | Pick one small feature or fix | "Add a score counter" |
| 2. Build | Code just that feature | Write the score variable + display |
| 3. Test | Run the new version with different inputs | Test correct answers, wrong answers, blank answers |
| 4. Get feedback | Notice what works, what doesn't | Score doesn't reset between rounds |
| 5. Refine | Plan the next iteration based on what you learned | Add a reset function in the next cycle |
Why this order matters:
The cycle starts with planning a small change, not a big one. Trying to build three features at once means testing won't tell you which feature broke things. One change per cycle keeps your testing focused.
When a stem describes build → test → fix → test again, the answer is almost always iterative development. When it asks for the best next step after vague feedback, look for answers that gather specific information before coding again — that is planning the next iteration with real data.
Iterative development catches errors early when they're easy to fix. Building everything at once means all the bugs hit at the same time, and finding the cause of each one is much harder. Iteration also gives you a working program at every stage, even if you run out of time.
| Building everything at once | Iterative development |
|---|---|
| Harder to find errors — bugs compound | Errors caught early, one at a time |
| You only have a working program at the end (maybe) | You have a working program after every cycle |
| Less user feedback during development | Feedback happens every cycle |
| Bigger risk of failure | Smaller improvements over time |
| One big test at the end | Many small tests throughout |
The deadline angle:
On the Create Task, students who iterate always have something to submit, even if it's not the final vision. Students who try to build everything at once sometimes have nothing working by the deadline.
How this shows up in the Create Task
The Create Task takes about 9 class hours, plus extra time at home. Students who plan 3-4 iterations finish stronger projects than students who try to build everything in one pass. Your written responses on exam day can also describe how testing changed your program from one version to the next — which directly maps to Row 6 of the rubric.
A strong Create Task project usually goes through 4-5 iterations. Each version adds one feature and gets tested before the next is added.
The simplest possible version. Show a single vocabulary term on the screen. That's it.
Test: Does the term display? ✓
Pick a random term from a list of 10 terms.
Test: Run 5 times — does each result come from the list? ✓
Show a term, let the user type a definition, and tell them if it matches.
Test: Correct answer says "Correct". Wrong answer says "Try again". Blank answer doesn't crash.
Add a score counter that increases by 1 for each correct answer.
Test: Score starts at 0. Score increases on correct. Score doesn't increase on wrong.
After every 5 questions, show the user which terms they missed most.
Test: Track missed terms accurately. Display correctly. Reset when a new round starts.
Why this matters for the Create Task:
By Version 5, you have a working program, code you understand, a procedure with a parameter (the answer-checker), a list (the vocabulary terms), and a clear algorithm. You'll have material for every row of the rubric — because every version produced its own testing notes. That is iterative development working as designed.
Strong iteration uses specific feedback, not vague feedback. "Make it better" doesn't help. "The next button is hard to find, and the score doesn't reset" gives you two concrete things to fix in the next iteration.
| Weak feedback | Strong feedback |
|---|---|
| "Make it better" | "The submit button is hard to find on mobile" |
| "It's confusing" | "After I answered, I didn't know if I was right" |
| "I don't like it" | "The score counter never updates" |
| "It's broken" | "When I leave the answer blank, the app crashes" |
How to ask for useful feedback:
After you refine from strong feedback, run the same user task again in the next cycle to confirm the fix worked — that closes the loop between feedback, refinement, and testing.
Read each before-and-after pair and pick which improvement was added in that iteration. You'll get immediate feedback and a short explanation — even when you're right.
Your progress is saved in this browser session, so you can refresh and continue where you left off. Miss a question? Re-read the five-version example above, then use Try again to run all six pairs again.
Question 1 of 6
Review the five-version example above, then try the AP-style questions below.
These patterns show up in student projects, Create Task responses, and released MCQs. Fixing them early keeps each cycle focused and testable.
| Mistake | Why it causes problems | Better approach |
|---|---|---|
| Building too many features in one iteration | If testing reveals a bug, you can't tell which feature caused it | One change per cycle, then test |
| Skipping the test phase to add another feature | Bugs compound and become harder to debug | Always test before moving on |
| Asking for vague feedback | Vague feedback doesn't help you decide what to change | Ask specific questions like "what confused you?" |
| Treating the first version as the final | You miss the chance to refine | Plan 3-5 iterations from the start |
| Iterating on documentation, not the program | Documentation matters, but not until the code works | Iterate on features first, document at the end |
| No plan for the next cycle | You add random features instead of meaningful ones | Each iteration should have a clear goal |
When a fix changes how the program behaves, document what you tried in that iteration — those notes become Row 6 testing evidence and help you write clearer program documentation later.
These five questions mirror common Unit 1 MCQ patterns: recognizing iteration in action, choosing the best iterative approach, planning small cycles, and turning vague feedback into a useful next step. Each question is labeled Easy, Medium, or Hard. Click an answer to see whether you are correct and read the explanation.
On your own Create Task timeline, sketch three planned iterations before you code — even a one-line goal per version ("v2: add list", "v3: check answers") keeps each cycle small and testable.
1. A student builds the first version of their program, tests it, identifies a bug, fixes the bug, and tests again. Which process is the student following?
Easy2. Which action best shows iterative development?
Easy3. A student wants to build a quiz app. Which approach best demonstrates iterative development?
Medium4. A student adds a score counter and a random-question picker in the same coding session without testing between them. What is the main risk?
Medium5. A student receives feedback from a classmate that says "the program is hard to use." What should the student do next to make this feedback useful for the next iteration?
HardTick each line when you can explain the idea without looking at the tables above. When all five are checked, continue to program testing — where you prove each iteration works with normal, edge, and invalid inputs.
0 of 5 ready
Iterative development is the practice of building a program in small, repeated cycles instead of all at once. Each cycle plans one small change, builds it, tests it, gets feedback, and refines based on what was learned. The result is a program that works at every stage and gets stronger with each pass.
Iteration catches errors early, when they're easier to fix. Building everything at once means all your bugs hit at the same time, and finding the cause of each one is much harder. Iteration also means you always have a working version — even if you run out of time, you can submit what you have.
One full iteration has 5 phases: plan a small change, build the simple version, test it, get feedback, and refine based on what you learned. Then you start the next cycle. The key is keeping each iteration small — one feature or one fix at a time, not three.
One-time development assumes you can write the final version perfectly on the first try. Iteration assumes you'll learn things along the way that change your plan. Real programmers almost always iterate because real problems are too complex to solve perfectly without testing.
A prototype is an early, simple version of your program. It might only do one thing, but it does that thing well enough to test. Prototypes let you learn what works before you build the full program — and on the Create Task, your first version is essentially a prototype.
The Create Task takes about 9 class hours, plus extra time at home. Students who iterate 3-5 times produce stronger projects than students who try to build everything in one pass. Your written responses on exam day can describe how testing changed your program from one version to the next.
Refinement is one step inside an iteration. Refinement means improving the program based on what testing showed. Iteration is the full cycle — plan, build, test, get feedback, refine — and then doing the next cycle. You refine inside an iteration; you iterate across multiple cycles.
Most strong Create Task projects go through 3-5 iterations. Fewer than 3 usually means the project is too simple or wasn't tested enough. More than 5 is fine but rarely needed in the 9-hour window. The right number is enough cycles that you can describe how your program changed from version 1 to the final version.