Understanding the Problem
This is step one of the problem-solving process, and the step most often skipped. Students read a question, recognise a familiar word, and start typing. The result is a program that solves a problem nobody asked about.
Pólya's advice in How to Solve It — a reference text for this course — begins with: you have to understand the problem.
The four questions
Ask all four before writing anything.
1. What am I given? (inputs) What data arrives? What type? What range? How much?
2. What must I produce? (outputs) What exactly is the answer? In what form and units?
3. What are the constraints? What rules must hold? What is forbidden? Any limits on time or memory?
4. How will I know it's correct? What test distinguishes a right answer from a wrong one?
If you cannot answer all four, you do not yet understand the problem, and any code you write is a guess.
Restate it in your own words
A reliable check: close the question paper and explain the problem to someone else. If you can't, you haven't understood it. Vagueness in your explanation marks exactly where your understanding stops.
Work a small example by hand
Before any code, solve one small instance on paper.
This does three things at once: it confirms you understand the problem, it often reveals the method, and it gives you a test case with a known answer.
If you cannot do it by hand for three items, you cannot write a program for a thousand.
Hunt for edge cases early
Edge cases are the unusual inputs where programs break. They are cheap to handle if you think of them now and expensive after the logic is written.
Standard checklist:
- Empty input — no numbers, an empty string, a file with nothing in it
- A single item
- All items identical
- Negative numbers, or zero
- The largest and smallest permitted values
- Invalid input — letters where digits were expected
For "find the average of n numbers", the edge case is : division by zero. Noticing that now costs one line. Noticing it in the lab exam costs marks.