B. Software Development · Software Development: Problem Solving, Design, Testing and the Life Cycle

Solving Problems Alone and in Teams, and Talking About Designs

B1.2 B2.2About 65 minutes

Learning goals

I can use good habits to solve programming problems on my own before asking for help, and ask for help clearly.
I can work as part of a programming team using pair programming and clear roles.
I can describe two different designs for the same program and compare them using correct vocabulary.
I can explain a program's structure in writing, out loud, and with a diagram.

Words to know

pair programming
Two programmers at one computer. The driver types; the navigator reviews and plans. They swap roles often.

driver / navigator
The two roles in pair programming: the driver controls the keyboard; the navigator watches for mistakes and thinks ahead.

code review
Reading someone else's code (or having yours read) to find bugs and suggest improvements before it is accepted.

alternative design
A different way to solve the same problem, for example using a formula instead of a loop.

trade-off
A gain in one area that costs something in another, such as faster code that is harder to read.

rubber duck debugging
Explaining your code, line by line, out loud to someone or something (even a toy duck). Saying it out loud often reveals the mistake.

efficiency
How much time (number of steps) or memory a design uses.

Coders are not lone wolves

Movies show programmers alone in dark rooms. Real software is built by teams: games, banking apps and the apps on your phone are usually made by groups of people who plan together, split the work, review each other's code and talk constantly.

But every team member also needs to solve problems independently. This lesson covers both: how to get yourself unstuck, how to work well with others, and how to talk about a design clearly so others can understand it.

Solving problems on your own

When you are stuck, try this ladder before asking someone:

Re-read the problem and your IPO chart. Are you solving the right problem?
Work a small example by hand. Compare what you did by hand with what the code does.
Read the error message carefully, especially the line number and the last line.
Explain your code out loud, line by line (rubber duck debugging).
Look it up in the official Python documentation or your notes.
Ask for help with a good question: what you expected, what actually happened, and what you already tried.

A good question gets a fast answer. "It doesn't work" gets the reply "What doesn't work?"

Working in a team

Pair programming is a common team technique. Two people share one computer:

The driver types and focuses on the line being written.
The navigator reads every line, catches typos and logic errors, and thinks about the overall plan and what comes next.

They swap roles often (every 15 to 20 minutes is a common choice), so both people understand all of the code.

Larger teams use divide and conquer (from the first lesson): each member builds one part, and the parts must fit together. That only works if the team agrees ahead of time on what each part receives and returns. Teams also hold code reviews, where someone else reads your code before it is accepted.

Pair programming: one keyboard, two roles. The driver works on the current line; the navigator watches the big picture. Swapping roles keeps both people involved.

Team habit	Why it matters
Agree on the plan (IPO chart, diagrams) before splitting work	Parts built separately will fit together
Agree on names and what each function receives and returns	Nobody's code breaks someone else's
Criticize the code, not the person	People keep sharing ideas and mistakes early
Keep one shared, up-to-date copy of the code	No one works on an old version
Report progress and problems early	The team can adjust before a deadline is missed

Habits of effective programming teams.

Talking about designs

There is almost never just one way to write a program. Two programs can give the same output but have different designs. To choose between them, a team must describe and compare them using clear vocabulary:

Correctness: does it give the right output for every input, including extreme cases?
Efficiency: how many steps does it take? How much memory?
Readability: can another person understand it quickly?
Maintainability and reuse: is it easy to change or reuse later?

You can describe a design in three modes: written (comments, a short design document), oral (explaining it to your team) and diagrammatic (a flow chart or structure chart; you will learn these in the next two lessons).

Worked example

Example 1: Comparing two designs

Your team must add up the whole numbers from 1 to n. Ana suggests a loop. Ben suggests the formula n(n + 1) ÷ 2. Describe and compare the two designs.

Design A (loop): start a total at 0 and add each number from 1 to n. For n = 1000 that is 1000 additions.
Design B (formula): calculate n × (n + 1) // 2 directly. That is about 3 operations no matter how large n is.
Correctness: both give 500500 for n = 1000 and 0 for n = 0 (an extreme case). Check both on a small case by hand: n = 4 gives 1 + 2 + 3 + 4 = 10 and 4 × 5 ÷ 2 = 10 ✓.
Trade-offs: B is far more efficient. A is easier to change if the problem changes (for example, "add only the even numbers", or "add the squares"). A comment in B should explain where the formula comes from.

Both designs are correct. Design B is more efficient; Design A is more flexible. A good team states the trade-off and picks the one that best fits the requirements.

Two alternative designs for adding 1 to n. The flow chart on the left repeats; the one on the right is a single calculation.

n = 1000

# Design A: loop

total = 0

for i in range(1, n + 1):

total = total + i

print("Design A:", total)

# Design B: formula (Gauss's trick)

print("Design B:", n * (n + 1) // 2)

Output: Design A: 500500 / Design B: 500500 (one line each)

Worked example

Example 2: Describing a program's structure in writing

Write a short description (3 or 4 sentences) of the HST program from the last lesson, using correct vocabulary.

Start with its purpose: what problem it solves and for whom.
Describe the input, processing and output using the variable names.
Mention data types and any constants.
Mention any limitations (extreme cases it does not handle).

"This program calculates Ontario HST for a store clerk. It reads one input, price, as a float. It multiplies by the constant tax rate 0.13 to get tax, adds it to get total, and outputs both rounded to 2 decimal places. It does not yet check for negative or non-numeric input."

Just for fun

Rubber duck debugging is a real technique, named in the 1999 programming book The Pragmatic Programmer: a programmer explains their code, line by line, to a rubber duck. The duck never says a word, yet it solves a surprising number of bugs.

Hands-on activity

Describe it, draw it

You need: a partner (family member or friend), paper, two pencils, and a computer with Python.

Oral description test. Draw a simple diagram of five boxes connected by arrows (any shape you like). Without showing it, describe it to your partner so they can draw it. They may ask questions; you may not point or gesture. Compare drawings. Which words caused confusion? This is why teams use agreed vocabulary and diagrams.
Pair programming. Write a program together that asks for a number n and prints the sum of the even numbers from 2 to n. One person drives for 10 minutes while the other navigates, then swap.
Reflect in writing: two things the navigator caught, and one thing that was hard about sharing a keyboard.

What to look for: for n = 10 the program should print 30 (2 + 4 + 6 + 8 + 10). The reflection should name specific events, not just "it went well".

Your turn

What are the two roles in pair programming, and what does each person do?

Rewrite this request for help so it is a good question: "My program is broken."

Name three things a team should agree on before splitting a program into parts.

Two designs both give correct output. Name three other qualities you could use to compare them.

Using the formula, what is 1 + 2 + ... + 200?

Give the three modes the curriculum lists for describing a design.

More practice: warm-up

True or false: in pair programming, the navigator does nothing until it is their turn to type.

What is rubber duck debugging?

What is a code review?

Which is more efficient for large n: adding 1 to n in a loop, or using n(n + 1) ÷ 2?

Name one step you should try before asking someone for help.

More practice: on your own

Ana's design checks if a number n is even with n % 2 == 0. Ben's design uses n // 2 * 2 == n. Are both correct? Compare them.

Write a 3-sentence written description of a program that reads a number of minutes and prints it as hours and minutes (for example 135 → 2 h 15 min).

A team of three splits a quiz program into: asking questions, marking answers and showing results. Ravi's marking function returns True/False for each answer, but Mei's results part expects the number of correct answers. What went wrong, and how could the team have prevented it?

Design A sums the squares 1² + 2² + ... + n² with a loop. Design B uses the formula n(n + 1)(2n + 1) ÷ 6. Check both give the same answer for n = 4.

Your partner's code works but uses variable names a, b, c. Write a respectful code-review comment.

Challenge

Design A to check whether a number n > 1 is prime tries every divisor from 2 to n − 1. Design B tries divisors only from 2 up to √n. For n = 10 007, roughly how many divisions does each design need in the worst case (when n is prime)? Explain why B is still correct.

A team of four has 2 weeks to build an app. Two members want to start coding immediately; two want to spend the first 3 days on design. Write a short paragraph (as you would say it in a team meeting) arguing for a compromise.

Explain why pair programming can produce fewer bugs even though only one person types.

Check your understanding

Quiz

In pair programming, who controls the keyboard?

Which is the best request for help?

Two programs give the same correct output. Which comparison is about efficiency?

What is 1 + 2 + 3 + ... + 100?

Which list gives the three modes of describing a design named in the curriculum?

Why should a team agree on what each function returns before splitting up?

For parents and teachers

Big idea: B1.2 asks students to solve problems both independently and as part of a team; B2.2 asks them to use proper vocabulary and written, oral and diagrammatic modes to describe alternative designs and explain a program's structure.

How to help: Be the "rubber duck": ask your teen to explain their program to you line by line. You do not need to know Python; just ask "What does this line do?" Try the "describe it, draw it" activity together; it is fun and shows why precise vocabulary matters.

Common difficulties:

Asking for help too early, or too late. Encourage the ladder (re-read, small example, error message, explain aloud, documentation, then ask).
In pairs, one person doing everything. Use a timer for role swaps.
Thinking the first working design is the only one. Ask "Is there another way? What would be better or worse about it?"
Feedback that is about the person rather than the code.