Week 7 — Discussion (Adaptive Learning) · "Break It Into Functions"

Course: Introduction to Computer Science — CS1 / Programming Fundamentals in Python (CSCI 1101) · Silver Oak University (fictional sample) · Prof. Okafor
Objective: Objective 5 (functions; decomposition into functions) · SLO A (program design) + SLO B (reason about how the pieces fit and behave)
This is Discussion 7 of 15 · Discussions group = 10% of the grade · Worth 20 points
Format: adaptive learning — instead of writing a post cold, you'll think it through in a real-time dialogue with your own AI, then post the short summary the AI writes with you (plus a link to your chat).

Part 1 — Student Instructions (read this first)

What this is. This week you'll do the design move at the heart of real programming: decomposition — taking a bigger task and breaking it into a set of well-chosen functions. You'll work it out in a back-and-forth with an AI chatbot, defend your breakdown, and weigh it against an alternative. The AI's job is to draw out and challenge your thinking — it will not write your post for you. When you've reasoned it through, it produces a short summary you post to the class.

The task to decompose (pick ONE):
- A receipt program — reads a few item prices, adds them up, applies a tax rate, maybe a discount, and prints a formatted receipt with a total.
- A quiz-scorer — takes a student's answers and the answer key, counts how many are correct, computes a percentage, and prints a pass/fail message.

There's no single right decomposition — that's the point. A reasonable design might have a function per responsibility (e.g., subtotal(prices), add_tax(amount, rate), format_line(name, price)), but how many functions, what each returns, and where to draw the lines are genuinely arguable. You'll defend your choices using two ideas from class: DRY (don't repeat yourself — if the same logic appears twice, it probably wants to be a function) and single responsibility (each function should do one clear job).

How to run it (about 15–20 minutes):
1. Open any approved AI chatbot — Gemini, Claude, or ChatGPT (free versions are fine).
2. Copy everything in the box below and paste it as one single message.
3. Have the conversation. Answer honestly and push back — the better you engage, the better your summary.

What to submit. When the AI gives you the DISCUSSION SUMMARY, copy it and your conversation's share link, and post both to the Week 7 discussion board as your initial post by Friday, Oct 16. Then reply to two classmates by Sunday, Oct 18 — compare their decomposition with yours: is one breakdown more DRY, or does one function do too many jobs?

Integrity note. The dialogue and the analysis are yours; the posted summary must reflect your reasoning, in your own words. (This is an adaptive-learning activity — you complete it with an approved chatbot, per the course AI policy.) You may sketch function names and signatures, but you do not need to submit working code for this discussion — it's about the design.

Part 2 — The Discussion-Partner Prompt (copy everything in the box)

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ COPY EVERYTHING BELOW THIS LINE ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

You are my discussion partner for Week 7 of Introduction to Computer Science (CSCI 1101) at Silver Oak University. We are going to have a real back-and-forth about how to break a bigger programming task into functions (decomposition), and whether my breakdown is better than an alternative. Your job is to draw out and challenge MY thinking through conversation — not to lecture me, and never to write my discussion post for me, and never to just hand me a finished design.

THE TASK WE'RE DESIGNING
I will pick ONE of these to decompose into functions:
- a receipt program (read item prices, sum them, apply a tax rate and maybe a discount, print a formatted receipt with a total), or
- a quiz-scorer (take a student's answers and an answer key, count correct answers, compute a percentage, print a pass/fail message).
I do NOT need to write full working code — we are designing: what functions should exist, what each takes in (parameters) and hands back (return), and why.

THE TWO DESIGN IDEAS WE'RE USING (from class)
- DRY — "don't repeat yourself": if the same logic shows up in more than one place, it probably wants to be its own function called from each place.
- Single responsibility: each function should do one clear job. A function that reads input AND does math AND prints a report is doing too much; splitting it usually makes the program easier to read, test, and fix.

WHAT WE'RE DIGGING INTO (use these privately to steer the conversation — do NOT read them to me as a checklist):
1. Which task I chose, and a first-pass list of functions with a name and a one-line job for each.
2. For each function, what it takes in and what it returns (vs. what it prints) — gently push me toward functions that return values the rest of the program can use, not functions that print everywhere.
3. Where my design repeats logic (a DRY smell) or where one function is doing two or three jobs (a single-responsibility smell) — make me find at least one place I'd refactor.
4. A genuine trade-off: more, smaller functions (very single-responsibility, but more pieces to track) vs. fewer, larger functions (fewer pieces, but each does more) — get me to take a position on where the line should be for THIS task, and weigh an alternative breakdown a classmate might choose.

HOW TO RUN THE DIALOGUE
- Open by greeting me warmly (2–3 sentences), asking my FIRST NAME, and asking which task I'm choosing and what the FIRST function I'd write is (its name and one-line job). (If I never give my name, keep going, but ask before the summary.)
- Exactly ONE question per message, then stop and wait. Never stack questions.
- Build on MY words: quote or paraphrase what I said, then go deeper — ask what a particular function should return, or point at two functions and ask whether they share logic that should be pulled out (DRY).
- Make me commit to a concrete list of functions with parameters and return values, then pressure-test it: find a spot that repeats, or a function doing too much, and ask me how I'd fix it.
- Introduce a real alternative decomposition (e.g., "another student wrapped the whole thing in one big make_receipt() function — why might that be worse, or actually fine for a tiny program?") so I have to defend or refine my view — present the trade-off fairly rather than declaring one breakdown obviously right.
- Keep YOUR messages short; I should be doing most of the thinking and talking.

ENGAGEMENT GUARDS
- Don't accept a vague answer like "I'd make some functions" — push for specific names, parameters, and return values ("Name it. What does it take in, and what does it hand back?").
- Don't lecture, and don't hand me a finished design or sentences I can paste as my post. If I ask you to "just design it for me," redirect with a question that helps me design it myself.
- If I go completely off-topic, give a brief friendly answer (a sentence or two) and then, IN THE SAME MESSAGE, steer us back.
- Until the summary, EVERY message must end with a question or a clear prompt to continue.
- Don't just agree with me — if my breakdown still repeats logic or still has a do-everything function, say so kindly and ask me to fix it.

THE EXIT CONDITION
After at least 5 substantive exchanges AND once I have (a) chosen a task and listed a concrete set of functions with names, parameters, and return values, (b) identified at least one DRY or single-responsibility improvement in my own design, (c) taken and defended a position on how finely to split THIS task into functions, and (d) weighed at least one alternative decomposition — whichever happens LAST — tell me we've had a good discussion and you'll summarize. Don't stop earlier; don't drag well past it.

THE DISCUSSION SUMMARY — produce it in EXACTLY this format, drawn ONLY from what I actually said (never invent a design I didn't propose):
WEEK 7 DISCUSSION SUMMARY — Break It Into Functions
Student: [name] | Date: ___
Task I chose: ___ (receipt program / quiz-scorer)
My functions (name → what it takes in → what it returns): ___
A DRY or single-responsibility fix I found in my own design: ___
How finely I'd split this task, and why (my position): ___
An alternative decomposition I weighed: ___
Then say, verbatim: "Copy this summary AND your share link to this chat, and post both to the Week 7 discussion board as your initial post — then reply to two classmates." End with one genuine sentence about something I reasoned well.

GETTING STARTED
Begin now: greet me, ask my first name, and ask which task I'm choosing and what my first function would be.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ COPY EVERYTHING ABOVE THIS LINE ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Participation rubric (instructor) — 20 points

Grading note (Prof. Okafor): the posted artifact is the AI-written summary + the chat share link; spot-check a few links against the summary. A glowing summary from a one-line chat is the failure mode to watch — the rubric rewards the design reasoning, not the AI's prose. This is a design discussion; full working code is not required.

Canvas placement block

canvas_object    = DiscussionTopic
title            = "Week 7 Discussion — Break It Into Functions (adaptive)"
assignment_group = "Discussions"
points_possible  = 20
grading_type     = points
discussion_type  = adaptive
due_offset_days  = 4     # initial post (AI summary + chat share link)
reply_offset_days = 6    # two peer replies
published        = true
submission_note  = "Initial post = the AI discussion summary + the chat share link; then reply to two classmates."
provenance       = "~ Prof. Okafor's edition · Fall 2026 · built with thecoursemaker.com"

Traditional variant — for comparison. This sample course is configured adaptive learning, so its actual Week-7 discussion is the BYOAI-dialogue version in G-discussion-week-07.md. This file shows the same Week-7 topic built the traditional way — an instructor-posted prompt where students write their own post and reply to peers — so you can see both formats side by side. (Choosing discussion_type = traditional at course setup generates this style instead.)

Course: Introduction to Computer Science — CS1 / Programming Fundamentals in Python (CSCI 1101) · Silver Oak University (fictional sample) · Prof. Okafor
Objective: Objective 5 (functions; decomposition into functions) · SLO A (program design) + SLO B (reason about how the pieces fit and behave)
Discussion 7 of 15 · Discussions group = 10% of the grade · Worth 20 points

The Discussion

This week you learned to package work into functions. The real skill behind functions is decomposition: taking a bigger task and breaking it into a set of well-chosen functions. Let's practice it — and argue about it, because there's no single right answer.

Pick ONE task to decompose into functions:
- A receipt program — reads a few item prices, adds them up, applies a tax rate (and maybe a discount), and prints a formatted receipt with a total.
- A quiz-scorer — takes a student's answers and the answer key, counts how many are correct, computes a percentage, and prints a pass/fail message.

Your initial post (by Friday, Oct 16 — about 150–200 words). Do all three:

• Part 1 — Your breakdown. List the functions you'd write. For each one, give its name, what it takes in (parameters), and what it returns (vs. what it prints). You can sketch signatures like add_tax(amount, rate) -> taxed amount; you do not need to submit full working code.
• Part 2 — Justify it with the two ideas from class. Point to where your design follows DRY (don't repeat yourself — the same logic isn't written twice) and single responsibility (each function does one clear job). If you spot a place your own first draft repeats logic or has a do-everything function, say how you'd fix it.
• Part 3 — Take a position. How finely should this task be split — many small functions, or a few larger ones? Defend your line for this task, and name one trade-off (more small functions = very single-responsibility but more pieces to track; fewer big ones = fewer pieces but each does more).

Replies (by Sunday, Oct 18). Reply to at least two classmates. Compare their decomposition with yours: is one breakdown more DRY? Does one function do too many jobs? Would you merge or split any of their functions, and why? One or two solid sentences each.

What a strong post looks like: "For the receipt program I'd write: subtotal(prices) → returns the sum; add_tax(amount, rate) → returns the taxed amount; apply_discount(amount, pct) → returns the reduced amount; and print_receipt(items, total) → prints the formatted output. That's single-responsibility: math functions return numbers, and only print_receipt does printing. It's DRY because tax logic lives in exactly one place — if the rate rule changes, I edit one function. I'd lean toward these four smaller functions over one big make_receipt(): it's easier to test add_tax on its own. The trade-off is more pieces to keep straight, but for anything beyond a toy program that's worth it."

Why this matters: decomposition is how real programs stay readable and fixable. A function with one clear job, that returns a value the rest of the program can use, is the unit everything else is built from — and it's exactly what the Week 8 Midterm expects you to be able to design.

Integrity & AI note. Write your post in your own words — that's the point of the exercise. You may use an approved chatbot (Gemini, Claude, or ChatGPT) to brainstorm or check an idea, but the post you submit must be your own thinking; if AI helped, add a one-line note saying which tool and how. (Note: this is the traditional format. In this course's actual adaptive discussion, working through the decomposition with the chatbot is the activity — see G-discussion-week-07.md.)

Participation rubric — 20 points

Grading note (Prof. Okafor): you read and grade each student's posted writing + their two replies against this rubric — the traditional flow. (The adaptive version instead has students submit an AI-dialogue summary + chat link.) Full working code is not required; this is a design discussion.

Canvas placement block

canvas_object    = DiscussionTopic
title            = "Week 7 Discussion — Break It Into Functions (traditional)"
assignment_group = "Discussions"
points_possible  = 20
grading_type     = points
discussion_type  = traditional
due_offset_days  = 4     # initial post
reply_offset_days = 6    # two peer replies
published        = true
submission_note  = "Students write an original initial post and reply to two classmates in the Canvas discussion."
provenance       = "~ Prof. Okafor's edition · Fall 2026 · built with thecoursemaker.com"