Creative Development
What this unit covers
The topics below follow the published CS Principles course framework for Unit 1. This unit is worth 10–13% of the exam, so budget your time against that rather than against how long the unit takes to teach.
Lessons in this unit
- Collaboration in Software Development12 min · 3 objectivesExplain why collaboration improves the quality of a computing artifact · Describe the roles and inclusive practices of an effective development team · Give and receive constructive feedback that improves a program
- Program Design & Development13 min · 3 objectivesDescribe the iterative phases of the software development process · Distinguish a program’s purpose from its function and its inputs/outputs · Explain how requirements and user needs drive design decisions
- Testing & Debugging13 min · 3 objectivesDistinguish syntax errors, runtime errors, and logic errors · Design test cases that include typical, boundary, and invalid inputs · Use tracing and test results to locate and fix a bug
- Documentation & Program Readability11 min · 3 objectivesExplain the purpose and audience of program documentation and comments · Distinguish documentation from the code it describes · Use meaningful names and comments to make a program maintainable
Formulas in Unit 1
Every term in Unit 1
All 24 terms we publish for Creative Development, with definitions. Reading them through is the fastest way to find the ones you cannot define — then drill those in cram mode until you can produce them without the prompt.
- Program
- A collection of statements that accomplishes a specific task. Every program has a purpose, and stating that purpose is the first thing the Create task asks for.
- Program purpose vs program function
- The purpose is why the program exists and who it is for. The function is what it actually does when run. Written responses lose points for describing one when asked for the other.
- Program input
- Data sent to a program by a user, a device, another program, or a file. The Create task requires at least one input that affects the program's output.
- Program output
- Any data a program sends out — to a screen, a file, a device, or another program. Sound, visuals and movement all count.
- Iterative development
- Repeatedly designing, implementing and reviewing in cycles rather than building once. The process CSP expects you to describe, not just perform.
- Incremental development
- Building and testing a program in small working pieces, then combining them. Reduces the search space when something breaks.
- Collaboration
- Working with others so that more perspectives shape the program. CSP treats it as a way to reduce bias and catch errors, not just to divide labor.
- Program documentation
- Written description of how a program or segment works, including comments in the code. It is for the next reader — often yourself in two months.
- Comment
- A note in source code ignored when the program runs. Good comments say why a segment exists, not what each line does.
- Program specification
- A description of what a program should do, agreed before it is written. Testing checks the program against the specification.
- Syntax error
- Code that breaks the language's rules, so the program will not run at all. The easiest kind to find, because something tells you.
- Logic error
- Code that runs but produces the wrong result. The hardest kind, because nothing reports it — only testing against expected output reveals it.
- Run-time error
- An error that occurs while the program is running, such as dividing by zero or indexing past the end of a list. The program starts and then fails.
- Overflow error
- A result too large for the storage allocated to it. The classic reason a counter suddenly goes negative.
- Debugging
- Finding and fixing errors. The methods CSP names are testing with different inputs, adding display statements, hand-tracing, and asking someone else to read it.
- Test case
- A specific input paired with the output it should produce. Good sets include typical values, boundary values and invalid values.
- Why test with edge cases
- Most logic errors live at the boundaries — an empty list, a single element, the first and last index, zero, a negative number. Testing only the typical case hides them.
- Hand-tracing
- Stepping through code on paper, tracking each variable's value line by line. The single most reliable technique for the code-reading questions on the exam.
- Create Performance Task
- A program you develop and submit with a video of it running and written responses about your code. Its written responses ask about your own program, so you must be able to explain your own algorithm and abstraction.
- Program code segment vs whole program
- The Create task asks you to identify specific segments — one showing an algorithm with sequencing, selection and iteration, and one showing a student-developed abstraction. Point to the code, not to a description of it.
- Acknowledging code you did not write
- Any code from an outside source must be cited. Using it is allowed; not saying so is a violation and can zero the task.
- Development process for the exam
- Investigate, design, prototype, test. You are expected to name where in that cycle a given activity sits.
- Why input matters to program behavior
- A program whose output never changes with input cannot demonstrate the Create task requirements. The input must reach the algorithm, not just be collected.
- Reducing bias in development
- Include diverse perspectives during design, test with users unlike yourself, and examine what your data leaves out. CSP treats this as an engineering practice, not an afterthought.
What examiners penalize here
- On the exam, tie collaboration to **quality**: diverse teams catch more problems and better serve varied users. Beware answer choices that overclaim — collaboration does not *guarantee* correctness or eliminate the need for testing.
- The exam loves the distinction: **syntax** = won’t run, **runtime** = crashes mid-execution, **logic** = runs but wrong. If a program produces an incorrect result without crashing, it is always a logic error.
- For the Create Performance Task you must write comments identifying key components of your program. Comments and meaningful names are graded parts of the artifact — treat documentation as part of the program, not an afterthought.
Practice CS Principles
Our practice bank is drawn from across the whole course rather than filtered to one unit, which is closer to how the exam asks anyway — it will not tell you which unit a question is testing.
Questions about this unit
How much of the AP Computer Science Principles exam is Unit 1?
Unit 1, Creative Development, is worth 10–13% of the CS Principles multiple-choice section according to the published course framework. Across all 5 units that makes it a substantial share — heavier than an even split would give it.
What topics are covered in CS Principles Unit 1?
Creative Development covers Collaboration, Program design, Testing and Documentation. We publish 24 terms with definitions for this unit, all of them on this page.
How should I study CS Principles Unit 1?
Read the 4 lessons below first — about 50 minutes — then drill the 24 terms in cram mode until you can produce each definition from memory rather than just recognize it. Recognition is what makes a unit feel finished when it is not. Finish with practice questions and read the explanation for every one you get right by elimination as well as the ones you miss.
All 5 units of AP Computer Science Principles
Unit names, topics and exam weights follow the published College Board course framework for AP Computer Science Principles. AP® is a trademark registered by the College Board, which does not endorse this site.