Start with the Problem, Not the Code

A blank editor has a talent for making a small project look enormous. The usual response is to start typing whatever code comes to mind.

Pause first. A few minutes of planning can turn “build a program” into a series of decisions you can actually make.

Describe the need

Chapter 12 will ask you to build a quiz engine about a subject you choose. Suppose someone describes it like this:

Make me an app with dictionaries, loops, and several functions.

That sounds specific, but it describes an implementation. It does not explain what the program should accomplish.

A useful problem statement starts with the experience instead:

I want to answer a short set of questions and see how many answers I got right.

Now you can ask productive questions:

• What information belongs to each question?

• What counts as a matching answer?

• What should happen when the learner enters nothing?

• What should the final result show?

• What is the smallest version that would already be useful?

The programming tools can wait a moment. First make sure you understand the result you are trying to create.

Write a small brief

A brief is a short description of the program and its boundaries:

Build a program that stores a quiz title and at least three question-and-answer records. Ask every question, compare answers while ignoring surrounding spaces and capitalization, and report how many answers were correct. If an answer is empty, ask that question again.

This brief says what the program receives, what rule it applies, and what it produces. It does not prescribe variable names or the exact number of functions.

Separate requirements from implementation

A requirement describes observable behavior:

• Ask every planned question.

• Treat answers with different capitalization or surrounding spaces as equal.

• Do not accept an empty answer.

• Report the number of correct answers.

An implementation choice describes how the code achieves that behavior:

• store each question in a dictionary;

• use a for loop to visit the questions;

• name the main function run_quiz.

Implementation choices matter, but they should serve the requirements. Starting with a favorite language feature can make you solve the wrong problem elegantly.

Cut a project down before building it up

The first version does not need accounts, a timer, an online leaderboard, or animated confetti for a perfect score. Those may become future improvements.

Use three scope labels:

• must: the smallest behavior that solves the stated problem;

• could: a useful improvement after the must-have behavior works;

• not now: an idea deliberately left outside this version.

“Not now” does not mean “never.” It protects the current project from becoming too large to finish or test. Scope trimming now can save an afternoon spent polishing the wrong program.

A repeatable starting routine

Before code:

1. Describe the user’s need in one or two sentences.

2. State the smallest useful result.

3. List the observable must-have behaviors.

4. Put attractive extras in “could” or “not now.”

5. Only then choose data structures, functions, loops, and conditions.

This chapter makes that routine explicit. You have already used parts of it in earlier projects. Now you will practice it as a skill of its own.