Evaluation of Computational Solutions

AQA 4.4 — Evaluating computational solutions

Retrieval: the previous lesson designed algorithms and justified individual decisions within them. This lesson asks a broader question about a finished solution: does it actually do what it was supposed to, and how could it be better?

Common mistake

Judging a solution only by whether it runs without crashing. "It works" and "it's a good solution" are not the same claim — a program can run successfully on every input you happened to test and still be a poor solution if it's slow, hard to read, fails on an input you didn't think to test, or doesn't actually meet the original requirement in some way.

A genuine evaluation framework

Evaluating a solution properly means checking it against several separate questions, not just one:

• Correctness — does it produce the right result for every valid input, including edge cases, not just the ones tested so far?
• Requirements met — does it actually do everything the original problem asked for, no more and no less?
• Efficiency — does it use a reasonable amount of time and memory for the problem's realistic scale?
• Readability and maintainability — could someone else (or you, in six months) understand and safely modify it?

Worked example — evaluating a solution

Consider the car_park_decision function from the previous lesson. Strength: it correctly prevents over-capacity entry, handling the key constraint. Weakness: it silently does nothing sensible if action is neither "enter" nor "exit" — it would return None, which could cause confusing failures elsewhere (recall Sequence 3's lesson on implicit None returns). Recommended refinement: add explicit handling for an unrecognised action, so the function fails clearly and predictably rather than silently.

Apply it — evaluate a solution yourself

Look back at your own solution to the "Apply it" task from the Algorithmic Thinking lesson (the library self-checkout algorithm). Evaluate it honestly against all four criteria above: correctness (does it handle every case you can think of?), requirements met, efficiency, and readability. Identify at least one genuine weakness and a specific refinement that would address it.

Challenge

Evaluate a program you wrote earlier in this course (any coding challenge or lesson exercise) using the same four-criteria framework, and write a short evaluation (four to six sentences) covering at least one strength and one weakness, with a specific, actionable refinement recommended for the weakness — not just "it could be better."

Looking ahead: the final lesson of this sequence (Computational Thinking Challenge) asks you to apply abstraction, decomposition, pattern recognition, algorithmic thinking and this lesson's evaluation skill together, on a solution of your own design from scratch.