AP CSP Big Idea 1 Program Design
AP CSP Program Design & Development: Complete Guide (2025‑2026)
Program design is the process of planning a program before and during writing it. AP CSP emphasizes iterative development: programs are built through repeated cycles of investigate → design → prototype → test → refine, not written perfectly on the first try. The exam tests your understanding of this process, the role of testing, and why programs often work differently than intended — requiring ongoing refinement.
Contents
The Iterative Development Cycle
Software is never written perfectly the first time. Iterative development acknowledges this and builds refinement into the process itself.
Each cycle through the loop produces a better program. The key insight: finding a design flaw in the Investigate phase costs far less than finding it after deployment.
A student is building a grade calculator app. She writes all the code before testing. When she finally runs it, she discovers: (1) it crashes when a student has no grades, (2) it calculates averages incorrectly for weighted grades, and (3) the interface confuses teachers about which field to enter first. All three issues require significant rework.
Which phase of iterative development did the student skip? What would have caught these issues earlier?
She skipped the test and refine phase within each cycle. Iterative development would have caught these at lower cost: testing with an empty grades list after the first prototype would have caught (1) immediately; testing with a few known inputs would have caught (2); showing a paper prototype to a teacher would have caught (3) before any code was written. The cost of fixing issues increases dramatically the later they are found.
Testing and Refinement
- Normal inputs: typical expected values
- Edge cases: empty list, zero, maximum
- Boundary values: exactly at the limit
- Invalid inputs: wrong type, out of range
- User behavior: unexpected interaction patterns
- Only test the “happy path” (inputs that work)
- Never test empty or null inputs
- Assume users will follow instructions
- Only test after all code is written
- Fix bugs without retesting adjacent features
A program calculates the average of a list of test scores. A student tests it with the input [85, 90, 78] and gets the correct result of 84.3. She concludes the program is correct.
Is this test sufficient? What cases has she failed to test?
Not sufficient. She tested one normal case. She has not tested: an empty list (which may cause a division-by-zero error), a list with one score (edge case), very large or very small numbers (boundary), duplicate scores, or non-numeric inputs. The AP exam specifically tests understanding of edge cases — the inputs most likely to reveal bugs are often the unusual ones, not the typical ones.
Design and Documentation
- Comments explain WHY, not just what
- Procedure names describe their purpose
- Parameters and return values are clear
- Complex logic has inline explanation
- Version history tracks changes and reasons
- No comments at all
- Variable names: x, y, temp, data
- Comments restate the code (‘x = x + 1 // add 1 to x’)
- Only the original author understands it
- No record of why design decisions were made
A programmer writes a working program and leaves the company. Six months later, a new programmer is asked to add a feature. The original code has no comments, all variables are named single letters, and there is no design documentation. The new programmer spends two weeks understanding the existing code before writing a single new line.
What development practice failure does this represent? What should the original programmer have done?
Documentation failure. Code is read far more often than it is written. The original programmer optimized for writing speed (no comments, short variable names) at the cost of the team’s long-term productivity. Good documentation includes: meaningful variable names, comments explaining non-obvious logic, and documentation of why design decisions were made (not just what the code does).
Common Exam Pitfalls
AP CSP explicitly tests iterative development. Programs are refined repeatedly. A first working prototype is the beginning, not the end.
Testing is the process of finding whether a program behaves correctly across inputs. Debugging is the process of fixing errors you have found. Testing should precede debugging, and both are ongoing throughout development.
Good documentation means clear, meaningful names and comments that explain WHY decisions were made — not restating what the code obviously does. A comment saying // add 1 to counter next to counter = counter + 1 adds no value.
The AP exam frequently presents programs with a bug that only appears on edge cases (empty list, zero input, maximum value). Testing only typical inputs is a design failure.
Check for Understanding
1. A development team releases a program, discovers bugs from user reports, fixes them, and releases an updated version. This process repeats multiple times. This best illustrates:
- A program that was poorly designed and should be rewritten from scratch.
- Iterative development, where programs are refined through repeated cycles of testing and improvement.
- A security vulnerability that requires patching.
- The waterfall development model, where each phase completes before the next begins.
2. A procedure findMax(list) is tested with [3, 7, 2, 9, 4] and returns 9 correctly. Which additional test case is most important to also run?
- findMax([1, 2, 3, 4, 5]) to test an ordered list.
- findMax([100, 200, 300]) to test larger numbers.
- findMax([]) to test behavior with an empty list.
- findMax([9, 9, 9]) to test all identical values.
findMax tries to access an element in an empty list without checking, it will crash. Edge cases like empty inputs reveal bugs that typical test cases never expose.3. Consider these statements about iterative development:
I. Programs are refined through repeated cycles of design, implementation, and testing.
II. A program is complete when it produces correct output for typical inputs.
III. Finding and fixing design problems earlier in development costs less than fixing them later.
Which statements are correct?
- I only
- I and II only
- I and III only
- I, II, and III
4. A programmer names her variables a, b, and c instead of studentCount, averageScore, and passingThreshold. Which problem does this most directly create?
- The program will run more slowly due to longer variable names.
- Other programmers (or the original programmer later) will have difficulty understanding and maintaining the code.
- The compiler will generate errors for variable names longer than one character.
- The program will use more memory with descriptive variable names.
5. During which phase of iterative development is it least expensive to identify and fix a design flaw?
- After deployment, when real users report problems.
- During testing, after the feature is fully implemented.
- During initial design and investigation, before code is written.
- During the prototype phase, after the first working version exists.
6. A student adds a comment to her code: # this line adds 1 to the counter variable next to the line counter = counter + 1. This comment is:
- An example of good documentation because it explains every line.
- Unhelpful, because it restates what the code obviously does without adding new information.
- Required by AP pseudocode conventions.
- An example of abstraction because it describes behavior without showing implementation.
Frequently Asked Questions
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]