What is software, really?

Status: drafted · Time: 5 min · Audience: anyone-curious Outcome: A one-sentence answer to what software is and why it matters.

The one-sentence answer

Software is instructions and data that make a computer perform a task.

Those instructions often begin as source code: text written by people, or generated by a tool and reviewed by people. A compiler, interpreter, or runtime then translates that source into operations the computer can execute. The hardware does not usually read a source file from top to bottom by itself.

If you remember one thing from this chapter, remember the first sentence. The translation detail explains why code can look readable to us and still run on a machine.

A useful shape for product work

When you need to reason about a feature, start with three questions:

Take some information in. A button click. A typed sentence. A photo. The current time. Your bank balance.
Do something to it. Add it up. Sort it. Search it. Compare it to something else. Translate it. Encrypt it.
Produce an output. A number on a screen. A new line in a chat. A confirmation page. A printed receipt. Sometimes it is an API response or a saved file that no user sees directly.

Input → process → output. That’s the bones.

A calculator: you type 2 + 2, the program adds the numbers, and it shows 4. A search engine: you type a query, the service looks through an index, and it shows the matches. A payment app: you tap a button, several services validate and record the attempt, and the app shows a status. The details differ, but input → process → output gives you a useful first sketch.

Real products usually add a fourth concern: state — information remembered between one action and the next. Your cart contents, account balance, and message history are state. Asking where state is read or changed often reveals more than staring at a loading spinner, which only tells you that the interface is waiting.

Cheap to copy, not free to run

Software has unusual economics: once a program exists, making another copy is usually cheap. Copying an app does not require rebuilding it from raw materials the way a second house does.

Running the copy still costs something. A service pays for compute, storage, network traffic, monitoring, security, support, and the people who keep it working. The thousandth order may be cheap compared with writing the system, but it is not free — and millions of orders can require very different architecture from ten.

That distinction is useful in product work:

Build cost is the effort to design, implement, test, and launch the software.
Run cost is what each use and each period of operation consumes.
Change cost is the effort and risk involved when the product, regulation, or surrounding systems change.

Software scales well when teams control all three. “We only build it once” is not a plan for operating it forever.

Where the instructions actually live

People usually work with source code: text files stored in a repository. We’ll cover repositories in chapter 0A.6. Source code can declare instructions, data shapes, configuration, and tests.

Before or while the program runs, another piece of software translates that source into lower-level instructions the processor understands. Different languages do this differently: some compile ahead of time, some use an interpreter, and many use a runtime that mixes both approaches. You do not need to memorise those paths yet. Keep the boundary: people and tools produce source; the toolchain turns it into something the machine executes.

The resulting program may run on your laptop, phone, a remote server, or several of them together. We’ll meet the client-server version of that conversation in chapter 0A.3.

The parts a product may need

A useful product often combines several parts, but none is mandatory for every program:

A way to keep state. A small program might keep data only in memory or a file. A shared product may use one or more databases, which we’ll cover in chapter 0A.4.
A place to process work. Some work happens on your device. Shared or sensitive work often happens on a server, the topic of chapter 0A.3.
An interface. People may use a screen, button, or page — a frontend or UI. Other software may use an API. A background job may have no user-facing interface at all.

These are design choices, not a checklist that every program must satisfy. The next chapters separate them so you can ask where a behaviour lives and what else it depends on.

Try it: map one familiar feature

Pick a feature you used today and fill in four lines:

Feature:        Send a payment
Input:          Amount, recipient, confirmation tap
Process/output: Validate request → record result → show status
State:          Payment status and account records

Now ask two questions: Where does each step run? What could fail between the steps? You do not need the correct architecture. The exercise turns a screen into a testable product flow — exactly the habit the next chapters build on.

What you should carry into the next chapter

Software is instructions and data that make a computer perform a task.
Source code is human-readable text; a compiler, interpreter, or runtime translates it into operations a processor can execute.
Input → process → output is a useful first sketch. Add state when the product remembers anything between actions.
Software is cheap to copy, not free to build, run, or change.
Databases, servers, UIs, APIs, files, and background jobs are possible parts of a product — not universal requirements.
The next chapter (0A.2 — Frontend vs Backend) separates two common areas of responsibility and shows how they communicate.

Previous: ← Tech 101 README · Next: → 0A.2 Frontend vs backend

Further reading

Julia Evans — How does the internet work? — a paid zine, but the friendliest illustrated tour of how machines talk to each other you’ll find
Paul Graham — Beating the Averages — an older essay on how programming-language choices shape what teams can build