Procedural Programming Revisited

AQA 4.1.2.2 — Procedural programming, evaluated

Retrieval: the previous lesson named procedural programming as one paradigm among several, without properly evaluating it. Every single program in this course, right up to and including Sequence 10, has genuinely been procedural — this lesson finally asks whether that was always the right choice.

Key vocabulary

• Procedure — a named, callable block of code (a function, in Python) that performs a task.
• Coupling — how tightly one part of a program depends on the internal details of another part.
• Cohesion — how closely the responsibilities within a single part of a program belong together.

Understand — what makes code genuinely "procedural"

Procedural code organises a program as a sequence of procedures, each operating on data that's passed to it or held separately (in variables, lists, dictionaries) outside those procedures. The data and the code that acts on it are two separate things, connected only by function calls and parameters — nothing bundles them together as one unit.

See it — a procedural system, growing

def create_student(name, year_group):
    return {"name": name, "year_group": year_group, "grades": []}

def add_grade(student, subject, grade):
    student["grades"].append((subject, grade))

def average_grade(student):
    if not student["grades"]:
        return 0
    return sum(g for _, g in student["grades"]) / len(student["grades"])

def print_report(student):
    print(f"{student['name']} (Year {student['year_group']}): average {average_grade(student):.1f}")

This works cleanly for a handful of functions. Now imagine the same system needing 15 more functions — remove_grade, promote_student, transfer_student, each one also taking a student dictionary as its first parameter, and each one needing to know its exact internal shape ("name", "year_group", "grades") to work at all.

Evaluate — where this genuinely strains

Every one of those functions is tightly coupled to the dictionary's exact structure: change "grades" to "scores" and every single function that touches it must be found and updated. Nothing stops a completely unrelated piece of code from directly writing student["grades"] = "invalid", since the dictionary has no way to protect its own structure. This isn't a flaw in the code shown — it's a genuine, structural limitation of separating data from the operations on it as a system grows, not a criticism of any individual function.

Common mistake

Concluding that procedural programming is simply "outdated" or "the wrong choice." It remains genuinely well-suited to many real tasks — scripts, one-off data processing, small utilities — where the coupling problem above never actually arises because the program never grows large enough to feel it. Evaluating a paradigm choice means weighing it against what the specific problem actually needs, not treating one paradigm as universally superior.

Check your understanding

A one-off script converts a single CSV file to JSON and exits. Evaluate whether the coupling/cohesion concerns raised above are a genuine reason to avoid procedural programming here. (No - a short-lived, single-purpose script that never grows or gets reused doesn't experience the scaling problem procedural code eventually faces; procedural programming remains a genuinely appropriate, simple choice for this specific kind of task.)

Challenge

For the student-record system above, propose (in words, not code) one specific change to how the data and functions are organised that would reduce the coupling problem you've identified — without yet using any new syntax you haven't learned.

Looking ahead: the next lesson introduces exactly the kind of change your Challenge answer was reaching for — Object-Oriented Programming, which bundles data and the functions that act on it into a single unit.