Performance Task

Overview

• The Create Performance Task is Section II of the AP CSP exam
• Worth 30% of your total exam score (a massive portion!)
• Requires at least 12 hours of dedicated class time to complete
• One comprehensive programming project with video and written responses
• Tests Computational Thinking Practices 1-4 through 6 rubric rows
• Must be completed and submitted to the AP Digital Portfolio before the deadline

The Create Performance Task isn't like a traditional exam - it's your chance to showcase what you've learned by creating something meaningful. You'll develop a program that interests you, create a video showing it in action, and write responses explaining your design decisions. Unlike the multiple-choice section that tests breadth, this task tests depth: can you actually build something that works and explain the computer science principles behind it?

The six rubric rows assess different aspects: Program Purpose and Function, Data Abstraction, Managing Complexity, Procedural Abstraction, Algorithm putting in place, and Testing. Each row is worth one point, making this essentially a 6-point task that's scaled to 30% of your exam score. Every point matters significantly.

Strategy Deep Dive

Success on the Create Performance Task requires understanding that you're being assessed on your ability to apply computer science principles, not just code. The College Board wants to see that you can design, put in place, and reflect on a computational solution. This is fundamentally different from just making something that works.

Choosing Your Project

The most successful projects find the sweet spot between personal interest and technical complexity. You need enough complexity to show abstraction and algorithms, but not so much that you can't complete it in the time allowed. The project must be entirely your own work (with some specific collaboration allowed during development), and it must be something you can explain clearly.

Avoid these common traps: Don't choose a project just because it seems impressive if you don't understand every line of code. Don't use complex libraries or APIs that do most of the work for you - the rubric assesses YOUR code, not library functions. Don't choose something so simple that you can't show the required concepts. A well-explained tic-tac-toe game beats a poorly-understood neural network every time.

Great projects often solve a personal problem or explore a personal interest. Past successful projects include grade calculators, simple games with interesting mechanics, data analysis tools for sports or hobbies, and creative applications like music or art generators. The key is that YOU drive the complexity through your algorithm and abstraction choices, not through importing sophisticated libraries.

Understanding Abstraction Requirements

The rubric specifically looks for two types of abstraction: data abstraction (using lists or other data structures) and procedural abstraction (creating procedures/functions). But It's important that many students miss: it's not enough to just use these features. You must explain how they manage complexity in your program.

For data abstraction, you need a list (or similar structure) that stores multiple values. But the rubric goes deeper - you must show how this list is essential to your program's function. A list that just stores high scores is less compelling than a list that represents the game state and gets processed by your algorithm. The key insight: your data structure should simplify what would otherwise be complex code.

For procedural abstraction, you need a student-developed procedure with at least one parameter. But again, the rubric wants more - you must explain how this procedure manages complexity. The best procedures don't just avoid code repetition; they encapsulate a complex process in a simple interface. Think about procedures that hide putting in place details while providing clear functionality.

Algorithm putting in place Excellence

Your algorithm needs to include sequencing, selection (if/else), and iteration (loops). But the rubric's algorithm requirement goes beyond just using these constructs - you need mathematical or logical concepts applied meaningfully. This is where many students struggle because they think "algorithm" means "any code that works."

Strong algorithms show clear problem-solving logic. They might involve searching through data structures, calculating results based on multiple inputs, or implementing game logic with multiple decision points. The algorithm should be substantial enough that explaining it requires real thought, but clear enough that you can describe it precisely in your written response.

The Testing Imperative

Testing isn't just running your program to see if it works. The rubric requires you to describe specific test cases and their results. More importantly, you need to show how testing led to improvements in your program. This demonstrates the iterative development process that real software engineers use.

Document your testing throughout development, not just at the end. Keep notes about bugs you found, how you fixed them, and what you learned. The best responses don't just say "I tested with different inputs." They explain the reasoning behind test case selection and how results informed program refinements.

Rubric Breakdown

Understanding what each rubric row actually assesses is crucial. The language seems straightforward, but there are specific things graders look for.

Row 1: Program Purpose and Function (1 point)

This isn't just describing what your program does - it's explaining the problem your program solves and demonstrating it actually works. Your video is crucial here. It must show:

• Input to your program (user interaction, data files, or hardcoded values all count)
• The program's functionality (what it does with that input)
• Output produced (what the user sees or what data is generated)

Common point loss: Videos that only show output without demonstrating input, or written responses that describe features without explaining the program's purpose. The graders want to see the "why" behind your program, not just the "what."

Row 2: Data Abstraction (1 point)

You must show:

• A list (or other collection) storing multiple values
• Usage of that list in your program
• Explanation of what the list represents

The critical part: the list must be necessary for your program's function. A list that stores three values when you could just use three variables won't earn this point. Show how using a list simplifies your code or enables functionality that would be impractical otherwise. Explain what the data in the list represents in your program's purpose.

Row 3: Managing Complexity (1 point)

This row specifically asks how your list manages complexity. You need to explain either:

• How the list allows the program to function in a way that wouldn't be feasible without it
• How the code would be more complex without using this list

Strong responses don't just say "it would require more variables." They explain specifically how the alternative approach would be problematic. Would it require hundreds of if-statements? Would it make adding new data impossible? Would it prevent certain algorithms from working? Be specific about the complexity being managed.

Row 4: Procedural Abstraction (1 point)

Requirements:

• A student-developed procedure with at least one parameter
• The procedure must be called in your program
• Description of the procedure's functionality

The parameter requirement is strict - the procedure must actually use the parameter in a meaningful way. Procedures without parameters or with unused parameters don't earn this point. Your description should explain what the procedure does, not line-by-line how it does it.

Row 5: Algorithm putting in place (1 point)

Your algorithm must include:

• Sequencing (steps in order)
• Selection (if/else decisions)
• Iteration (loops)

But beyond these basics, you need to explain the algorithm in enough detail that someone else could recreate it. This doesn't mean line-by-line code explanation - it means explaining the logic and flow. Use clear language to describe how the algorithm accomplishes its goal. Mathematical or logical concepts should be evident in your explanation.

Row 6: Testing (1 point)

Describe two specific test cases:

• The specific input you tested
• The expected result
• The actual result
• How this testing led to refinement

Avoid vague descriptions like "I tested with different values." Instead: "I tested with a negative number input, expecting an error message, but the program crashed. This led me to add input validation that checks for negative values before processing." The key is showing how testing improved your program.

Common Pitfalls and How to Avoid Them

Understanding where students typically lose points helps you avoid these issues entirely.

The Collaboration Confusion

You can collaborate during ideation and development, including debugging. You CANNOT collaborate on your video or written responses. This is where many students accidentally commit plagiarism. If you worked with a partner on similar projects, your written responses must be entirely your own words about your own program. Even paraphrasing a partner's response is plagiarism.

The Library Trap

Using libraries and APIs is allowed, but you must credit them, and more importantly, the rubric points come from YOUR code. If a library handles all your data management or implements your core algorithm, you can't earn those points. Use libraries for auxiliary functions (like graphics or file I/O) while ensuring your core computer science concepts are implemented in your own code.

The Complexity Paradox

Some students create overly complex programs thinking it will impress graders. In reality, this often backfires because they can't explain their code clearly. A moderate-complexity program with excellent explanations beats a complex program with vague descriptions every time. Choose complexity you can confidently explain.

The Video Visibility Issue

Technical problems with videos cause unnecessary point loss. Ensure your video clearly shows input being provided and output being produced. Screen recordings should be high enough resolution to see details. If using a phone camera to record a physical computing project, ensure good lighting and steady recording. Test your video on a different device to ensure it's viewable.

The Last-Minute Documentation Disaster

Writing responses after finishing your program is harder than documenting as you go. Keep a development journal noting your design decisions, abstraction choices, and testing results. When it's time to write responses, you'll have rich material to draw from rather than trying to remember your thought process weeks later.

Time Management Reality

The 12+ hours of class time sounds generous, but it disappears quickly without good planning. Here's a realistic timeline that successful students follow:

Hours 1-2: Ideation and Planning Brainstorm ideas, sketch out your program structure, identify the abstractions you'll need. This feels slow when you're eager to code, but planning prevents major rewrites later. Decide on your data structures and main procedures before writing any code.

Hours 3-8: Core Development Build your program incrementally. Start with basic functionality, then add features. Test continuously - don't wait until everything is "done." During this phase, document your decisions in a development journal. Note why you chose certain data structures, how your procedures manage complexity, and what algorithms you're implementing.

Hours 9-10: Testing and Refinement Systematic testing with documented test cases. This isn't just fixing bugs - it's demonstrating the iterative development process. Keep records of what you test, what fails, and how you fix it. This provides rich material for your testing written response.

Hours 11-12: Video and Written Responses Create your video showing input, functionality, and output. Write your responses using your development journal as reference. Don't rush this - clear communication is as important as functional code. Review your responses against the rubric to ensure you're addressing what's actually being asked.

Writing Response Excellence

Each written response has specific requirements. Understanding the verbs used in the prompts is crucial.

"Describe" vs "Explain" When asked to describe, provide the relevant features or characteristics. When asked to explain, provide the reasoning behind your choices or how something works. Description is "what," explanation is "how" or "why."

Code Segments When including code segments, only include what's relevant to the prompt. Don't paste your entire program. Use comments to point out key features if the programming environment allows. If it doesn't, add clarifying notes when you capture the code.

Specific Language Use computer science vocabulary precisely. A "list" is a specific data structure, not just any collection of items. An "algorithm" involves logical steps to solve a problem, not just any code. "Iteration" means loops, not just repetition. Precise language demonstrates understanding.

Concrete Examples When explaining how abstractions manage complexity, use specific examples from your program. Don't just say "it would be harder without the list." Explain exactly what code you would need without the list and why that approach would be problematic.

Final Thoughts

The Create Performance Task is your opportunity to show real computer science skills. Unlike the multiple-choice section that tests recognition and analysis, this task tests creation and reflection. It's not about building the most impressive program - it's about building something you understand deeply and can explain clearly.

Success comes from balancing ambition with ability. Choose a project that genuinely interests you but that you can complete confidently. Build in abstractions because they make your program better, not just because the rubric requires them. Test systematically because it improves your code, not just for the points.

Remember that this task assesses your journey as much as your destination. The rubric rewards thoughtful development process, clear abstraction choices, and reflective testing. Document your thinking throughout development. When you explain your choices in the written responses, draw on this documentation to provide rich, specific examples.

The students who earn full points aren't necessarily the most advanced programmers. They're the ones who understand computer science principles and can communicate that understanding clearly. They choose appropriate projects, put in place meaningful abstractions, and explain their choices precisely. They treat the task as an opportunity to showcase their learning, not just a requirement to fulfill.

Start early, plan carefully, and document continuously. Build something you're proud of and can explain confidently. The Create Performance Task is challenging but entirely manageable with the right approach. Trust in your ability to apply what you've learned, and let your genuine interest in your project shine through in your responses.