Input → Process → Output
What is it?
Almost every useful program follows one shape: it takes some input (data to work on — a file, a number, a list, user input), does some processing (transforms, calculates or decides based on that data), and produces output (a result — a printed value, a new file, a report). Input → process → output (IPO) is the skeleton underneath scripts of every size, from a one-liner to a large automation. Naming the three parts is how you understand an unfamiliar script and how you design a new one.
Why it matters
IPO gives you a way in to any program: find what it takes, what it does, and what it produces, and you understand its purpose. And when building, thinking in IPO turns a vague 'automate this' into three concrete questions — what's my input, what transformation is needed, what output do I want? — which is the starting point of designing every script in this path.
Where you see it
In every script: reading a file (input), transforming its data (process), writing a result (output); in command-line tools (arguments in, result out); and as the mental frame for designing any automation.
What normal looks like
A clear, identifiable input, a well-defined transformation, and a definite output — each part distinct. A well-designed script's three parts are easy to point to, which makes it easy to understand and test.
What suspicious looks like
For design/debugging: if you can't clearly name the input, the process, or the output, the task isn't well understood yet — and a bug is often in whichever part you glossed over (wrong input assumed, a process step missing, output not what was asked for).
How analysts investigate
By splitting any script (to read it) or any task (to build it) into the three parts: what goes in, what is done to it, what comes out. Understanding a program is naming its IPO; designing one is deciding its IPO before writing a line.
Common beginner mistakes
- Jumping to code before deciding the output you actually want. If you don't know what the result should be, you can't tell whether the process is right — decide the output first, then work back to the input and process.
- Confusing the process with the output. Transforming data (process) and presenting the result (output) are different steps; conflating them makes scripts hard to read and reuse.
Look closely at any script and the same skeleton appears. Orbit's file-renaming script takes a folder of files (input), works out each file's new standard name (process), and writes the renamed files (output). A report script reads a data file (input), sums and groups the numbers (process), and prints a summary (output). Even a one-liner that adds tax to a price is input (the price), process (add the tax), output (print the total). This shape — input → process → output — is the frame you use to understand any program and to design a new one.
INPUT -> PROCESS -> OUTPUT (the shape underneath almost every script)
data to transform / a result
work on calculate / (printed value,
(file, decide on new file,
number, the input report)
list)
Example (sales report):
sales.csv -> sum the amounts, group by region -> print a per-region total
Design by deciding the OUTPUT first, then the INPUT and PROCESS that produce it.# INPUT -> PROCESS -> OUTPUT in four lines
price = 100 # INPUT: the data to work on
tax = price * 0.15 # PROCESS: compute the tax from the input
total = price + tax # PROCESS: combine into the result
print('Total:', total) # OUTPUT: present the result -> Total: 115.0
The power of IPO is twofold. To understand an unfamiliar script, find its three parts: what does it read or take in (input)? what does it do to that data (process)? what does it produce (output)? Once you can name them, you understand what the script is for. To design a new script, work the shape deliberately — and, counter-intuitively, start from the output. Decide exactly what result you want (a per-region sales total, a list of files renamed, a report of which servers are down); that tells you what input you'll need and what processing connects the two. Beginners often start typing code with only a vague goal, then can't tell if it's working because they never pinned down the output. Deciding the output first turns 'automate the sales report' into three answerable questions: output = a per-region total; input = the sales data file; process = read it, sum amounts grouped by region. Keep the process (transforming data) distinct from the output (presenting it) — that separation is what will let you reuse and test each part later in the path. IPO is the design method you'll apply, at growing scale, in every remaining unit.
Designing a script from the output backwards
Orbit's manager asks: 'automate our daily server check — I want to know each morning which of our servers are down.' Turn this into an IPO design before writing any code.
Decide the OUTPUT first.
Start from what the manager actually wants: a clear morning report listing which servers are down (and ideally which are up). That's the output — a list, say a short report of 'DOWN: server-3, server-7'. Fixing the output first is what makes the rest concrete: now we know exactly what the script must produce, so we can judge whether it's correct. A beginner might start by writing code to ping a server; but without deciding the output, they wouldn't know when they're done.
Identify the INPUT the output requires.
To produce that report, what does the script need to take in? The list of servers to check (their names or addresses) — probably from a file or a defined list. That's the input. Notice we derived the input FROM the output: because the output is 'which of our servers are down', the input must be 'the set of our servers'. Working backwards keeps the design honest — every input exists to serve the output.
Define the PROCESS that connects them.
The process is whatever turns the input into the output: for each server in the list, check whether it responds; collect the ones that don't; format that collection into the report. Now the whole design is stated as IPO — input: the server list; process: check each and collect the non-responders; output: the morning down-report — before a line of code. This is exactly how every script in this path will be designed: decide the output, derive the input, define the process. And note the process ('check each, collect failures') is distinct from the output ('format the report'), which will let each part be built and tested on its own. Decision/lesson: IPO, worked output-first, converts a vague request into a concrete, checkable plan.
Quick check
What are the three parts of the shape that underlies almost every program?
A quick self-check — it doesn't affect your XP or progress.
Quick check
When designing a new script, which part is it most useful to decide FIRST?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.