What software is, and why it is engineered — COMP 410

Software is three things, not one

Ask a room of programmers what software is and you will hear “programs” or “code”. On this paper that answer earns about one mark of seven, because it names one part of three. Software is (1) the instructions that, when executed, provide the features, function and performance that were asked for, (2) the data structures those instructions manipulate, and (3) the descriptive information, in print and in virtual form, that describes how the programs are operated and used. Drop the third clause and you have not defined software — you have defined a build artefact.

It is worth saying out loud what that third clause covers: the requirements model, the design model, the interface reference, the runbook, the test specification. All of it is part of the thing being engineered, which is why all of it gets reviewed, versioned and baselined alongside the code.

The thinking move to keep: whenever a question mentions software, ask which of the three parts is at stake. Changing the late-fee rate changes instructions. Changing what a reservation record holds changes data structures. Changing the grace period without writing down why changes neither — and that is precisely why the next engineer gets it wrong.

Engineered, not manufactured

Software is a logical rather than a physical element of a system. It has no production line worth the name: once the design exists, copies cost nothing and every copy is identical. Everything expensive, and everything risky, therefore sits in design and construction rather than in production. That single asymmetry is why software is engineered rather than manufactured, and it carries a consequence the rest of this course leans on — you cannot inspect quality in at the end of a line, because there is no line. Whatever quality the product has was put there by the process that produced the design.

It does not wear out — it deteriorates

Physical components follow a bathtub-shaped failure curve: relatively many failures early from design and manufacturing faults, then a long low steady state, then a rise as dust, heat, vibration and fatigue do their work. Software meets none of those enemies, so in an idealised world its failure rate would fall as early defects were removed and then stay flat forever.

That is not what happens, because software gets changed. Every change carries some chance of introducing a defect, so the real curve spikes at each release; before the rate settles back another change arrives and spikes it again, and the floor creeps upward release over release. That is deterioration, and its cause is change rather than use. There is a second difference worth a mark: there are no spare parts. A worn bearing is replaced by an identical bearing; a failing module cannot be, because an identical module carries the identical fault. Every software failure points back into design.

Software engineering as a layered technology

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. Those last two words matter, because that is where most of the money goes. It is usefully pictured as four layers resting on one another. At the bedrock is a quality focus — an organisational commitment without which nothing above it holds. On that sits process, the glue: it defines the framework of activities, says which work products are produced, where the milestones fall, how quality is assured and how change is managed. On the process sit methods, the technical how-to for communication, requirements analysis, design modelling, construction, testing and support. On top sit tools, automated or semi-automated support; when tools are integrated so that one can consume another's output, you have computer-aided software engineering.

The layering is a claim about dependency, not a diagram: a layer delivers value only through the layers beneath it.

Worked example — the same tool, two BorrowBox teams

BorrowBox is a neighbourhood tool library. Members reserve a power tool in a mobile app, collect it from a bank of smart lockers with a one-time code, and return it to any locker for a librarian to inspect. Two teams build it, and both buy the same static-analysis tool.

Team A has no defined review action inside its modelling activity and no agreed exit condition for a design. The tool reports 412 warnings on its first run; someone triages them for an afternoon, and the rule set is muted. Team B has a review method — a walkthrough of the design model with a recorder — and a process that will not baseline a design until that review closes. Its 412 warnings are filtered to the nine that touch the locker-token path, and the review that reads them finds a state transition with no guard on an expired hold.

Same tool, different result, because Team B had three layers underneath it. That is the example to reach for whenever a question asks why buying tools does not make an organisation an engineering organisation.

Read it as a dependency claim, not a picture. Team A in the worked example bought the top band and owned none of the three beneath it, so the band delivered nothing.

The whole distinction lives in the third and fourth rows. Hardware degrades through use; software degrades through change, and the absence of spare parts is why every failure is a design question.