Week 15 Discussion — Who Is Responsible When Software Fails?

Hook

A class is written once and used many times, often by people who never read its code. This week you saw a reading log whose add_day method left self. off one line: it added 45 pages, printed no error at all, and print(mine.pages_read) still showed 0. You also saw the pinned Cat("Milo") program stop with AttributeError because one line in __init__ stored nothing on the object. One slip was loud and one was silent, and either could end up inside software that other people trust.

Your driving question — choose Option A or Option B; they carry the same weight and the same rubric, and you say which you picked.

Option A: A small class, such as a step tracker, a bike-share dock, or a reading log, is written by one person and reused by another, and its method has the missing-self bug, so the count never changes and no error appears. Pick one setting from your own life, major, or workplace where that class might run, and take a position on who is most responsible when it fails: the person who wrote the class, the person who reused it without running a check, or the group that shipped the program. Use this week's ideas (class, instance, method, state, missing-self bug) and say what someone who weighs individual and shared responsibility differently from you would argue.

Option B: A student asks a chatbot for a class, pastes it into a project without running it, and later learns that one method only prints when it should return a value, so the next step receives None. Pick one kind of program you use or could imagine writing and take a position on who is responsible for that failure: the student who pasted the code, the tool that produced it, or the people who decide how such tools are used. Use this week's ideas (method, self, return versus print, attribute) and say what someone who weighs speed and accountability differently from you would argue.

There is no single right answer. People who agree on every fact about what a class does still disagree about where responsibility belongs when code fails, because that question rests on judgment about who could have checked, who was trusted, and who pays for the failure, as well as on the facts about Python.

Both answers have a strong case. Those who place responsibility on individuals argue that the person who writes a line of code, or who reuses it, is the one who can see it and run it, and that one short run with two values would have caught either slip; if each person checks what they write or reuse, a failure stops where it starts. Those who place it on the group argue that a slip such as a missing self. is predictable in any team, so the dependable fix is a shared practice, such as a required test run or a review before release, and that blaming one person leaves open the gap that let the bug through. Option B splits the same way: one side holds that code from any tool is a draft its user must run before trusting it; the other holds that the people who build such tools and set the rules for their use shape how much checking users are led to expect, and so share the cost when that checking does not happen.

Expectations

Activity format: a multi-exchange dialogue or an equivalent structured written exchange, followed by one discussion-board post. Plan on about 45 minutes for either route, and post by the due date your instructor sets in Canvas.

There are two ways to complete this discussion. They are worth the same 10 points and scored by the same rubric. Pick either one.

Route A — the AI dialogue (the default). Hold a real conversation about the driving question with your own chatbot, then post what it produces:

1. Open any approved chatbot in a new conversation.
2. Copy the entire prompt box below and paste it as your first message.
3. Have the conversation. It will ask you questions and push back; it will not write your post for you and will not stop after one word from you.
4. Post the chatbot's summary report plus the conversation's share link to the Week 15 discussion board. That post is your entire submission. You may post the summary as text, or record it as audio or video with a transcript attached; both forms are scored by the same rubric.

No replies to classmates are required.

Route B — the written route. See Equivalent route (no AI required) below.

Integrity note. Whichever route you take, the thinking and the words you post are your own. If you mention what a class prints or which exception type it raises, say that you ran it; do not rely on a chatbot's prediction alone. Do not name a real company, product, or person as the example of a failure; describe a setting in your own words instead.

Discussion Partner Prompt

ROLE: You are my discussion partner for an introductory computer science course
taught in Python 3. Your job is to draw out and challenge MY thinking about the
question below. You will never write my post for me and never hand me a
conclusion - you ask questions that make me reason it through. Never invent a
statistic, a study, a law, a court case, or a quotation, and never name a real
company, product, or person as an example of a failure. Never tell me what a
class prints or which exception type it raises; if it matters, ask me to run it
and tell you what I saw. On any question of who is responsible when software
fails, present the strongest case on each side and pick no side yourself.

THE QUESTION I AM EXPLORING (two options of equal weight - ask which one I choose first):
Option A: A small class, such as a step tracker, a bike-share dock, or a
reading log, is written by one person and reused by another, and its method
has the missing-self bug, so the count never changes and no error appears. I
pick one setting from my own life, major, or workplace where that class might
run, and take a position on who is most responsible when it fails: the person
who wrote the class, the person who reused it without running a check, or the
group that shipped the program. I use this week's ideas (class, instance,
method, state, missing-self bug) and say what someone who weighs individual
and shared responsibility differently from me would argue.
Option B: A student asks a chatbot for a class, pastes it into a project
without running it, and later learns that one method only prints when it
should return a value, so the next step receives None. I pick one kind of
program I use or could imagine writing and take a position on who is
responsible for that failure: the student who pasted the code, the tool that
produced it, or the people who decide how such tools are used. I use this
week's ideas (method, self, return versus print, attribute) and say what
someone who weighs speed and accountability differently from me would argue.

REFLECTION TARGETS (steer toward these; never read this list aloud to me):
- whether I name a specific setting or kind of program, not only a general
  feeling about blame
- whether I describe what the faulty class actually does, such as a method
  that stores a value in a local name instead of on self
- whether I keep a loud failure (an exception that stops the run) distinct
  from a silent one (a logic error that prints the wrong value)
- whether I name who could have checked the code, and what a check would have
  looked like
- whether I can state the strongest case for a view I do not hold, and name
  something I would run to check a factual part of my argument

DIALOGUE RULES: greet me warmly and ask my first name before your first content
question. If I decline or give no name, call me "there" and continue without
pressure. If you still do not know my name when the summary is due, ask once more;
if I decline again, use "Discussion participant." Never invent a name. Ask ONE
question per message, then wait. Build on my exact words without praising agreement
or calling every reply "great." Probe unsupported claims and introduce the
strongest fair counterpoint. Praise only a specific, earned move I actually made,
such as revising a claim or answering the counterpoint. Never accept a one-word
reply - ask again, differently. Never lecture. Every message you send before the
summary ends with a question.

EXIT CONDITION: continue until this exact boolean is true — at least five substantive exchanges AND the student has stated a position AND provided at least one reason OR example AND engaged with one fair counterpoint, stopping only after whichever threshold happens LAST. A reason alone or an example alone can satisfy the support branch; do not require both, and do not require that I "answered" the counterpoint. A greeting, my name, or a one-word reply is not a substantive exchange.

THEN produce a summary report using exactly these eight labelled fields in this
order, drawn only from what I actually said. If I never supplied a field, write
"Not supplied" rather than inventing it:
  1. STUDENT NAME
  2. POSITION
  3. REASON
  4. EXAMPLE
  5. COURSE CONCEPTS
  6. COUNTERPOINT
  7. RESPONSE TO THE COUNTERPOINT
  8. OPEN QUESTION OR NEXT CHECK
Do not mention an initial post or replies to peers or classmates.
REQUIRED CLOSING — perform these final two instructions exactly:
Then say, verbatim: "Copy this summary AND your share link to this chat, and post both to the Week 15 discussion board — that completes the assignment."
Then END with one genuine earned-praise sentence that names a real move the student made.

Equivalent route (no AI required)

You never have to create an account with a chatbot company to earn full credit in this course. This route assesses the same objectives as the AI dialogue — defining a class with __init__, attributes, and methods, telling a method that returns from one that only prints, and checking a claim about a class by running it — against the same driving question and the same rubric below, for the same 10 points. Choosing it costs you nothing, and you do not have to tell me why you chose it.

What you do. Write a structured written exchange with yourself — the same back-and-forth the dialogue would have produced, on paper:

1. Your position (roughly 150 words). Answer Option A or Option B. For Option A, name the setting, describe in words what the faulty class does, and say who is most responsible when it fails, and why. For Option B, name the kind of program, describe the method that prints instead of returning, and say who is responsible, and why. Use this week's terms (class, instance, method, self, attribute, state, missing-self bug) correctly.
2. The strongest objection (roughly 100 words). Write the best argument against your own position that you can — for example, the case that whoever writes a line of code owns what it does, or the case that a team which ships a program without a single test run shares the blame for every bug inside it. Argue it honestly; a weak objection you knock over earns no credit.
3. Your response to it (roughly 100 words). Say what you still hold, what changed, and which part of the disagreement is about what Python does and which is about judgment.
4. One thing you would still check (one or two sentences). What would you run, such as the class with and without self. on the line that stores the count, or a print of what the method hands back, to settle the factual part of your argument?

Effort. Roughly 350–400 words of your own writing, comparable to the time the AI dialogue takes — about forty-five minutes including the thinking.

What you submit. Post those four parts, under those four labels, as your Week 15 discussion post. That post is your entire submission; this route has no share link.

Participation rubric

This discussion is worth 10 points. The same three criteria score both routes.

Built with The Course Maker · samples.thecoursemaker.com