Traditional Programming Paradigms and Workflows

1. Setting the Stage: Traditional vs. AI-Assisted Programming

Before AI coding assistants and agents became common (roughly before 2022–2023), most professional software development followed human‑centric, manual workflows.

In this module you will:

• Distinguish procedural, object‑oriented, and functional paradigms at a conceptual level.
• Walk through a typical traditional workflow from feature request to deployment.
• See how teams historically measured code quality and productivity.
• Identify limitations of purely manual coding at scale.

Keep in mind:

• All of these paradigms and workflows are still in use today (2026).
• What changed is how we work with them: AI tools now assist, but the core concepts remain the same.

You can think of this module as learning the "manual driving" of software development: understanding the fundamentals that underlie both traditional and AI‑assisted workflows.

2. Procedural Programming: Step‑by‑Step Recipes

Procedural programming is the oldest mainstream paradigm you’ll see in modern languages. It organizes code as a sequence of procedures (also called functions or subroutines).

Core idea:

• The program is a step‑by‑step recipe for the computer.
• Data is stored in variables and structures.
• Procedures read and modify this shared data.

Key characteristics:

• Top‑down flow: `main()` calls functions, which call other functions.
• Stateful: functions often change global or shared state.
• Often uses loops (`for`, `while`) and conditionals (`if`, `switch`).

Common procedural languages / styles:

• C (classic example)
• Early versions of languages like Pascal, Fortran
• Scripting in Bash, early PHP, or Python written in a procedural style

Mental model:

Imagine you are writing instructions for a robot:

1. Turn on.
2. Read input.
3. Do step A, then step B, then step C.
4. Print result.

That’s procedural programming: explicit control flow and explicit steps.

3. Example: Procedural vs. Object‑Oriented vs. Functional (Conceptual)

Below is a simplified example in a Python‑like pseudocode to illustrate the same task (calculating the total price of items in a cart with tax) in different paradigms.

3.1 Procedural Style

```python

Shared data structure

cart_items = [

{"name": "Book", "price": 10.0},

{"name": "Pen", "price": 2.0}

]

TAX_RATE = 0.2 # 20%

Procedures (functions) operate on data

def calculate_subtotal(items):

subtotal = 0

for item in items:

subtotal += item["price"]

return subtotal

def calculatetotalwith_tax(items):

subtotal = calculate_subtotal(items)

return subtotal * (1 + TAX_RATE)

Main flow

subtotal = calculatesubtotal(cartitems)

print("Subtotal:", subtotal)

print("Total with tax:", calculatetotalwithtax(cartitems))

```

3.2 Object‑Oriented Style

```python

class CartItem:

def init(self, name, price):

self.name = name

self.price = price

class Cart:

TAX_RATE = 0.2

def init(self):

self.items = []

def add_item(self, item):

self.items.append(item)

def subtotal(self):

return sum(item.price for item in self.items)

def totalwithtax(self):

return self.subtotal() * (1 + self.TAX_RATE)

cart = Cart()

cart.add_item(CartItem("Book", 10.0))

cart.add_item(CartItem("Pen", 2.0))

print("Subtotal:", cart.subtotal())

print("Total with tax:", cart.totalwithtax())

```

3.3 Functional Style

```python

from functools import reduce

cart_items = [

{"name": "Book", "price": 10.0},

{"name": "Pen", "price": 2.0}

]

TAX_RATE = 0.2

Pure functions: no mutation, same input -> same output

def get_price(item):

return item["price"]

subtotal = reduce(lambda acc, item: acc + getprice(item), cartitems, 0)

totalwithtax = subtotal * (1 + TAX_RATE)

print("Subtotal:", subtotal)

print("Total with tax:", totalwithtax)

```

Focus less on syntax and more on structure:

• Procedural: functions + shared data, explicit steps.
• OOP: objects encapsulate data + behavior.
• Functional: data flows through pure functions and transformations.

4. Object‑Oriented and Functional Paradigms: Core Concepts

Object‑Oriented Programming (OOP)

Core idea:

• Model the world as objects that contain both state (data) and behavior (methods).

Key concepts (industry‑standard terms):

• Class: blueprint for objects (e.g., `User`, `Order`).
• Object / Instance: concrete example of a class.
• Encapsulation: hide internal details; expose a clear interface.
• Inheritance: one class derives from another (e.g., `AdminUser` from `User`).
• Polymorphism: different objects can be used through a common interface (e.g., `Shape.draw()` for `Circle` and `Square`).

Common OOP languages / styles:

• Java, C#, C++, Python, Ruby, many modern frameworks.

---

Functional Programming (FP)

Core idea:

• Build programs by composing pure functions and avoiding mutable state and side effects.

Key concepts:

• Pure function: output depends only on input; no external state changes.
• Immutability: data structures are not modified; new versions are created.
• Higher‑order functions: functions that take or return other functions (e.g., `map`, `filter`, `reduce`).
• Function composition: building complex behavior by combining simpler functions.

Common functional languages / styles:

• Haskell, OCaml, F#, Scala (functional‑first or mixed),
• Functional style in JavaScript (with `map/filter/reduce`), modern Java, Kotlin, and C#.

In real projects, paradigms are often mixed. For example, a Java application may be largely OOP but still use functional features like lambdas and streams.

5. Thought Exercise: Match Problems to Paradigms

Consider these three problems. For each, choose which paradigm feels most natural and explain why in 1–2 sentences (mentally or in notes):

1. Low‑level device driver that needs to manage memory and hardware registers very precisely.
2. Large business application with many types of users, products, and workflows (e.g., an e‑commerce platform).
3. Data transformation pipeline that takes raw logs, filters them, aggregates metrics, and outputs reports.

Reflect:

• Which would you choose procedural for, and why?
• Which are more naturally object‑oriented?
• Where does a functional style shine?

There are no perfectly right answers, but typical industry reasoning is:

• Low‑level, performance‑critical: often procedural or OOP in a procedural style (e.g., C).
• Rich domain models, many entities: often OOP.
• Data pipelines and transformations: often functional or functional‑style.

Write down your choices, then compare them with a classmate or discuss in a study group.

6. Traditional Workflow: From Feature Request to Deployment

In a pre‑AI, human‑centric workflow (still widely used today, just with more tooling), a feature typically moved through these stages:

1. Requirement / Feature Request

• Source: product managers, customers, business stakeholders.
• Output: user stories, specs (e.g., "As a user, I want to reset my password.").

1. Design

• Decide which paradigm(s) fit: procedural scripts, OOP services, functional pipelines.
• Create diagrams (UML, sequence diagrams), API contracts, database schemas.

1. Manual Coding in an IDE

• Developer writes code by hand in an IDE (e.g., IntelliJ, Visual Studio, VS Code without AI extensions).
• Uses language features: classes, functions, modules, etc.

1. Local Build & Compilation

• Run compiler or build tool (e.g., `javac`, `gcc`, Maven, Gradle, `npm run build`).
• Fix syntax and type errors manually.

1. Local Testing & Debugging

• Write and run unit tests (e.g., JUnit, pytest).
• Use a debugger: breakpoints, step‑through, inspect variables.

1. Version Control Commit & Push

• Use Git (or older tools like SVN, Mercurial) to commit changes with messages.
• Push to a shared remote repository (e.g., GitHub, GitLab, Bitbucket).

1. Code Review (Human‑Only)

• Open a pull request / merge request.
• Other developers review diffs, comment, request changes.
• No AI auto‑review; quality relies on human expertise.

1. CI/CD Pipeline (Scripted, Not AI‑Driven)

• CI server (e.g., Jenkins, GitLab CI, CircleCI) automatically:
• Checks out code.
• Builds and runs tests.
• Possibly runs static analysis (e.g., SonarQube, ESLint).
• CD pipeline deploys to staging / production once checks pass.

1. Monitoring & Manual Incident Response

• Logs and metrics monitored via tools (e.g., Prometheus, Grafana, ELK stack).
• Humans investigate incidents, roll back releases, apply hotfixes.

Throughout this flow, every step is manually initiated or scripted by humans. Automation exists (CI/CD, scripts), but no AI decides what to code or how to fix things.

7. Quiz: Identify the Workflow Stage

Match the described activity to the correct workflow stage in a traditional process.

8. Traditional Productivity & Quality Metrics

Historically, teams have used several human‑centric metrics to track productivity and quality. Many are still used, but often with more nuance today.

Productivity Metrics

1. Lines of Code (LOC)

• Counts how many lines were written or changed.
• Easy to measure, but controversial:
• More lines ≠ better code (can indicate verbosity or duplication).
• Encourages quantity over quality.

1. Velocity (in Agile / Scrum)

• Measures how many story points a team completes in a sprint.
• Story points estimate relative effort/complexity, not time.
• Used for planning, but can be misused as a performance score.

1. Lead Time for Changes

• Time from code committed to running in production.
• Shorter lead times usually indicate a more efficient pipeline.

1. Cycle Time

• Time from work started (e.g., ticket in progress) to work completed (merged/deployed).

Quality Metrics

1. Defect Density

• Number of bugs per KLOC (thousand lines of code) or per feature.

1. Code Coverage

• Percentage of code executed by automated tests.
• High coverage doesn’t guarantee good tests, but low coverage is a warning sign.

1. Static Analysis Findings

• Tools like SonarQube, ESLint, or FindBugs report code smells, potential bugs, and security issues.

In traditional workflows, these metrics are produced by tools but interpreted by humans. There is no AI automatically adjusting plans or code based on them; instead, managers and engineers discuss and decide how to improve.

9. Interactive Reflection: Metric Trade‑Offs

Consider this scenario:

> Your team’s velocity increased from 30 to 45 story points per sprint over the last month, but the number of production bugs also increased.

Reflect on these questions (write down short answers):

1. Why might higher velocity not always mean better outcomes?
2. Which additional metrics would you look at to understand what’s happening (e.g., defect density, lead time, code coverage)?
3. What non‑quantitative signals might you consider (developer burnout, rushed reviews, unclear requirements)?

This exercise mirrors what real teams do in retrospectives: they interpret metrics in context, rather than treating them as absolute truth.

10. Structural Limitations of Manual, Human‑Only Workflows

Traditional, manual workflows scale up to large systems, but they have structural limitations, especially as systems and teams grow.

Here are at least two major limitations to be able to articulate clearly:

1. Cognitive Overload in Large Codebases

• As systems grow to millions of lines of code, no single developer can hold all details in their head.
• Understanding the impact of a change (dependencies, side effects) becomes slow and error‑prone.
• Onboarding new developers is expensive and time‑consuming.

1. Slow Feedback Loops

• Manual coding + manual review + long test suites can mean hours or days before you learn if a change is safe.
• Long feedback loops discourage experimentation and refactoring.

1. Human Bottlenecks in Code Review

• Senior engineers reviewing many pull requests become a throughput bottleneck.
• Reviews can be shallow under time pressure, missing subtle bugs or design issues.

1. Repetitive Boilerplate & Error‑Prone Tasks

• Writing similar code patterns (APIs, DTOs, mappings) over and over wastes human attention.
• Repetition increases the chance of copy‑paste bugs and inconsistencies.

1. Limited Exploration of Alternatives

• Manually trying multiple designs or refactorings is expensive.
• Teams often settle for "good enough" designs rather than exploring broader solution spaces.

These limitations are part of what motivated the rise of more automation (CI/CD, static analysis) and, more recently, AI‑assisted and agentic programming tools. Understanding the manual baseline helps you see exactly what AI is trying to augment or replace.

11. Flashcards: Key Terms Review

Flip these cards (mentally or with a partner) to reinforce core concepts from this module.