Module 16 — Challenge Problems¶

Three open problems, all at the top of the course's scale. The first is more engineering; the second and third are judgement, and the third turns that judgement on this course.

The demand they share: every claim rests on something you produced. A file count, a run, a comparison — not an impression. That is the difference between the last module of this course and the first.

Challenge 1 — Give the application a second front end [L6 Build]¶

The problem. Take the finished application and drive it from a second interface — a command-line script format (one command per line, a batch file), or a file-driven mode that runs a sequence of operations — without duplicating the domain logic.

What a good answer contains.

The domain layer unchanged. Not "mostly unchanged": the lending rules, the catalogue operations and the persistence code are not copied, and they do not learn about the front end. If they had to change, say what had to be separated to make that possible, and why the separation was missing.
The seam named. Which type the front end talks to, what it passes, and where the response is formatted. A front end should be a parser, a call and a printer.
Output that is evidence, not narration. A script that exercises lending, an attempt to lend an unavailable item, a save, a reload, and a report — with the two runs (interactive and scripted) producing the same domain behaviour, compared.
The errors routed sensibly. A failed operation in a script must not end the batch, and the exit status must reflect whether anything failed — a small design decision that reveals whether failure is modelled or caught ad hoc.
One thing that had to change, and its cost. Something always does. Naming it is the answer to "how reusable was my design, really?"

What would make it weak. A second main that reimplements the rules. A front end that reaches into the catalogue's internals. Or a scripted mode that only prints a transcript of calls without any behaviour being observable — which proves nothing about the domain.

Deciding it for yourself. The test of whether the domain is separable: could you write the batch mode in a file that includes one of your headers? If yes, the layering is real. If it needs three, the front end is entangled and you have found a design finding worth more than the feature.

Challenge 2 — Review somebody else's implementation [L8 Evaluate]¶

The problem. Review another student's capstone against the published rubric — or your own from an earlier milestone, which is harder and more honest. Write the review you would want to receive: specific, fair, and about the code rather than the author.

What a good answer contains.

Findings tied to evidence: a file, a line, a behaviour, and the requirement that would be expensive as a result. "load() assigns to books_ inside the loop, so a file truncated halfway leaves a half-loaded catalogue; requirement 7 says a rejection leaves the data untouched."
At least one strength with the same standard of evidence. A review with no positives is as uninformative as one with no findings, and in a self-review it is usually the weaker discipline.
A priority order. Which two findings are worth a student's remaining time, and which can wait. A list of eleven equal problems has judged none of them.
The rubric's language, so the review is comparable with somebody else's: correctness, design, object orientation, resource management, failure handling, code quality, documentation, testing.
A counter-case engaged with. Before criticising a decision, state the requirement it was made for and whether that requirement was plausible. Some decisions that read as mistakes were correct trades.
The limits of your review: what you did not run, what you assumed, which requirement you could not test from the outside.

What would make it weak. Findings without evidence ("this class is too big"). Severity invented to sound thorough. A review that concludes the work is fine — on a first capstone, essentially impossible, which means the reading has not been done. Or the reverse: a review that lists everything, ordered by nothing, so the reader finishes it knowing less than when they started.

Deciding it for yourself. The measure of a review is what its reader can do afterwards. Before finishing, check that each finding could be acted on by a stranger without asking you what you meant. Unactionable findings are opinions: sharpen them with evidence, or cut them.

Challenge 3 — Judge the course you have just finished [L8 Evaluate]¶

The problem. This course built one system across sixteen labs, starting with parallel global arrays and ending with a designed, persistent, tested application. Was that the right structure for teaching object-oriented programming?

Name what it achieved, and one thing a different structure would have taught better.

What a good answer contains.

A specific achievement, with the mechanism. Not "it was good to build one thing" but which understanding came from continuity: e.g. living with an earlier decision and discovering its cost from code that already existed, which a series of unrelated exercises never produces.
A specific cost. Which topic had no natural home in a library system, and what you learned less well as a result: concurrency, file formats other than text, an event loop, a network boundary, a performance-critical path, a GUI. Name the technique, and say what the library system forced you to improvise rather than learn.
A concrete alternative, with its own cost. "Use five different systems" trades continuity for breadth; "use only the library system" trades breadth for depth. Say which you would choose for a student like yourself, and what you would give up.
One addition you would make to the course, small enough to be implementable: an extra module, a different lab sequence, a required measurement, a review of somebody else's work.
A judgement about your own learning, with evidence: which module's lab did you complete with less understanding than the checklist implies? That answer is worth more than a ranking of the topics.

What would make it weak. Praise without mechanism. Criticism without a cost to the alternative. An answer that avoids the second half of the question — one thing a different structure would have taught better — because that is the whole exercise.

Deciding it for yourself. The honest test of the judgement: would you say it to the instructor, and could they act on it? An evaluation that nobody could act on is an opinion with a heading. This course spent a module on the difference; this is where it is applied to the course itself.

Evaluating your own answer¶

Write these five lines before reading any suggested approach:

The claim I am making:
The evidence I produced for it (a run, a count, a file list, a comparison):
The cost of the option I chose:
The option I rejected, and its cost:
What would change my mind:

Then check it against four tests:

Is there evidence? This module's exit level is 8, and evaluation rests on things you produced: a batch that ran, a review with line numbers, a file count from a real extension.
Is a cost named? A second front end costs a seam and a decision about error reporting; a review costs honesty about limits; a judgement about the course costs naming what the course did worse.
Was the counter-case engaged with? Every challenge here has a defensible opposite answer. An answer that does not say what the opposite would have bought has skipped the comparison.
Is it actionable? Somebody reading it should know what to do next — a file to split, a message to improve, a test to add, a module to teach differently.

Levels: [L6 Build] · [L8 Evaluate] — Challenge 1 is the level-6 extension exercise in the blueprint, and Challenges 2 and 3 are the exit level: judging a design with the rubric's standards, and then judging the teaching that produced it. There is no level 9, and there is no Module 17; this is where the course's own material is the thing under review.

Next: Self-assessment — fifteen questions, diagnostic rather than marked, and the audit that decides whether the capstone is finished.