Problem-Solving, Pseudocode and Algorithm Design

A large problem is not solved by staring at it harder. It is solved by turning it into several small problems you already know how to do. That conversion is the real skill in programming, and it is entirely separate from knowing Java syntax — which is why a good designer can plan a program in a language they have never used. Five strategies do most of the work.

Every program is input, then processing, then output. An IPO chart writes those three columns down before anything else, and it is the fastest way to discover that a requirement is impossible — if a value appears in the processing column but was never an input, you have found a gap while it is still free to fix.

Pseudocode is the logic of a program written in structured English, with no language syntax to get wrong. It has no official rules, but useful pseudocode is consistent: capitalize the keywords, indent the bodies, and use one line per action. The point is that you can get the logic wrong ten times in two minutes, instead of once in two hours.

PSEUDOCODE - average of n values entered by the user

READ n
IF n <= 0 THEN
    DISPLAY "You must enter at least one value"
    STOP
END IF

SET total TO 0
FOR i FROM 1 TO n
    READ value
    SET total TO total + value
END FOR

SET average TO total / n
DISPLAY "The average is", average

import java.util.Scanner;

public class AverageCalculator {
    public static void main(String[] args) {
        Scanner input = new Scanner(System.in);

        System.out.print("How many values? ");
        int n = input.nextInt();

        if (n <= 0) {
            System.out.println("You must enter at least one value");
            return;
        }

        double total = 0;
        for (int i = 1; i <= n; i++) {
            System.out.print("Value " + i + ": ");
            total += input.nextDouble();
        }

        double average = total / n;
        System.out.println("The average is " + average);
    }
}

A flowchart draws the same logic as a path rather than a list. It is better than pseudocode at one specific thing: showing every route through a decision at a glance, including the route you forgot. A diamond asks a yes or no question, so exactly two arrows must leave it and both must lead somewhere. If a diamond has an arrow leaving only one side, you have just found a missing case before writing a line of code — and a dangling exit in a flowchart becomes a missing else in the program, where the code silently does nothing at all.

When someone hands you a specification, the algorithm is not yours to invent freely — it must meet every stated condition. Read it with a highlighter and mark three things: the exact inputs and their valid ranges, the exact outputs and their formatting, and every boundary word. Words such as inclusive, at least, up to and no more than each decide between < and <=, and each one of them is a bug waiting to happen.

1. Underline every noun in the specification — these become your variables and arrays.
2. Underline every verb — these become your methods and processing steps.
3. Circle every number, limit and boundary word, and write down which comparison operator it implies.
4. Write the IPO chart, and check that every processing value traces back to a real input.
5. Write the pseudocode, then hand-trace it on the smallest case you can think of.
6. Only now open the editor.