Computer Science · 11th Grade

Active learning ideas

Software Design Principles: Modularity

Students learn modularity best when they actively experience its value rather than just hear about it. Breaking down programs by hand and comparing messy versus clean structures helps them see why modularity matters for readability, debugging, and teamwork. Active learning turns an abstract concept into a tangible skill they can apply immediately.

• Common Core State Standards
• CSTA: 3B-AP-15
• CSTA: 3B-AP-17

• 20–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Think-Pair-Share
• 20 min · Pairs

Think-Pair-Share: Decomposing a Real App

Show students a screenshot of a familiar app (like a school gradebook or social media feed) and ask them to individually list what they think the main modules might be. Partners then compare their decompositions and reconcile differences before sharing with the class. Discuss why different valid decompositions exist.

Explain the concept of modularity in software design.

Facilitation Tip

For Think-Pair-Share, assign real apps students know, like a music player or chat app, and ask them to sketch a modular map on paper before discussing.

What to look for

Present students with a short program (e.g., 50 lines of Python) that is not modular. Ask them to identify two potential modules they could extract and write down the purpose of each. Then, ask them to list one benefit of doing so.

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Activity 02

• Case Study Analysis
• 25 min · Small Groups

Card Sort: Responsibilities to Modules

Give groups a set of cards describing application behaviors (e.g., 'validate login', 'store user preferences', 'display search results') and ask them to group cards into named modules. Groups share their structures and justify their choices, then compare against a professional architecture for the same system.

Analyze how breaking down software into smaller, independent modules improves development.

Facilitation Tip

In Card Sort, provide blank index cards so students write module names and responsibilities, then physically group them to test their reasoning.

What to look for

Pose this scenario: 'Imagine you are part of a team developing a web application. One team member has written a large function that handles user authentication, database interaction, and email notifications. What are the potential problems with this approach, and how would you refactor it using modularity?'

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 03

• Gallery Walk
• 30 min · Small Groups

Gallery Walk: Monolith vs. Modular Code

Post printed examples of spaghetti code and modular code solving the same problem around the room. Students rotate with sticky notes to annotate what makes each hard or easy to maintain, change, or test. Debrief by building a shared list of modularity signals.

Justify the benefits of modular design for collaboration and code reuse.

Facilitation Tip

During the Gallery Walk, require each group to post one question about the monolith or modular code they are examining for peers to answer.

What to look for

Provide students with a simple class definition. Ask them to write down one method that could be extracted into its own separate function or helper class, explaining why this would improve modularity and what the new module's responsibility would be.

• Understand
• Apply
• Analyze
• Create
• Relationship Skills
• Social Awareness

Activity 04

• Case Study Analysis
• 40 min · Pairs

Refactor Sprint: Modularizing Student Code

Students take a working but monolithic program they wrote earlier in the year and spend a focused session extracting functions or classes into logical modules. Partners review each other's refactored structure and suggest improvements. Conclude with a brief reflection on what changed.

Explain the concept of modularity in software design.

Facilitation Tip

Run the Refactor Sprint in pairs so one student explains the refactoring steps while the other checks for preserved behavior.

What to look for

Present students with a short program (e.g., 50 lines of Python) that is not modular. Ask them to identify two potential modules they could extract and write down the purpose of each. Then, ask them to list one benefit of doing so.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

A few notes on teaching this unit

Teach modularity by letting students feel the pain of tangled code first. Start with small, broken programs so the benefits of refactoring become obvious. Avoid lecturing about abstraction until after students have struggled with a monolith. Research shows that students grasp separation of concerns more deeply when they refactor messy code they can touch and break rather than just study. Always connect modularity to debugging and collaboration, not just organization.

Students will articulate how modularity improves code structure, identify clear module responsibilities, and practice refactoring toward better separation of concerns. Successful learning shows up as students confidently discussing cohesion versus coupling and proposing meaningful module boundaries in their own work.

---

Watch Out for These Misconceptions

• During Card Sort: Responsibilities to Modules, watch for students believing that any split into smaller parts equals good modularity.

  During Card Sort, have students physically group responsibilities by shared state or behavior and then argue why some groupings resist clear splitting. Ask them to count the resulting modules and compare to the original code size. This reveals that over-modularization inflates complexity without clear benefit.

• During Gallery Walk: Monolith vs. Modular Code, watch for students assuming modular code is always longer or more complex because it shows more files.

  During Gallery Walk, ask students to compare the total lines of code and the clarity of each module’s purpose. Have them trace a single feature through both versions to show how modularity reduces cognitive load even when the file count increases.

• During Refactor Sprint: Modularizing Student Code, watch for students equating adding more functions with modularity.

  During Refactor Sprint, require students to write a one-sentence purpose for each new module and explain how it interacts with other modules. This forces them to focus on separation of responsibilities rather than just function count.

---

Methods used in this brief

• Think-Pair-Share
• Case Study Analysis
• Gallery Walk