The word “engineering” was applied to software deliberately, not descriptively. At a 1968 NATO conference in Garmisch, computer scientists chose the phrase “software engineering” as a provocation—an aspirational demand that the discipline impose on itself the rigor that physics imposes on civil and mechanical work. The word was not a recognition; it was a challenge. Fifty years later, the challenge remains unresolved. And the discomfort that trained engineers feel when they move into software—the sense that the ground is somehow less solid, the rules more negotiable, the stakes harder to calibrate—is not a failure of imagination. It is a correct perception of something genuinely different.

I. The 1968 provocation

The “software crisis” of the late 1960s was real: large software projects were consistently late, over budget, unreliable, and impossible to maintain. The NATO conference was convened specifically to address this panic. The choice of the word “engineering” was strategic—it imported the connotation of rigor, discipline, and systematic method into a field that was operating largely as craft, a domain where problems were solved by intuition and heroic individual effort rather than reproducible method.

Edsger Dijkstra, who was at Garmisch, was skeptical of the metaphor. He thought software was closer to mathematics than to engineering—that its correct foundation was formal reasoning, not physical analogy. He was probably right about the foundation and probably wrong to think this made the engineering framing useless. The two are not contradictory: mathematics provides the foundation; engineering provides the discipline of application under real-world constraints. You can reason about a program formally and still need to manage its interaction with the physical world, other systems, schedules, and the finite patience of users.

II. The spectrum of constraints

What classical engineering imposes is not merely rigor—it is external rigor. The engineer does not get to choose whether the bridge obeys the load equation. The constraint comes from outside the system, enforced by matter itself. A weight will fall. A beam will bend. A material will corrode. The physical world is a merciless teacher.

What software engineering must impose is internal rigor. There is no thermodynamics of code. A program can allocate memory indefinitely; a bridge cannot grow without material. A software system can reach a state space of astronomical size without violating a single physical law. The constraint in software is not physical entropy but logical complexity—and logical complexity does not announce itself until it has already accumulated into a system nobody can modify without fear.

This is the “permissiveness” that trained engineers notice when they cross into software. It is not that software has no constraints. It is that the constraints are not automatically enforced. You have to build them yourself, into the tests, the type systems, the contracts, the review processes, the documentation, the team structure. In electronics, the constraint is built into the material. In software, it must be carved into the culture. The work is the same; the medium does not help you the way matter helps a structural engineer by simply refusing to cooperate with wrong designs.

Fred Brooks called this the difference between essence and accident in The Mythical Man-Month. The essence of software is conceptual complexity—the problem space itself. The accidents are the tools, languages, and platforms we use to express that complexity. You can make the accidents easier, but you cannot eliminate the essential difficulty. And in a medium where the material is completely permissive, where anything you type is syntactically valid until you try to run it, you have to impose the discipline that other media impose for free.

III. Where systems engineering fits

Ludwig von Bertalanffy’s General System Theory made a claim that at the time seemed almost trivial: that the same organizational principles appear across physical, biological, and informational systems. A cell and a corporation and a circuit board are all, at some level of description, systems of interacting components whose emergent behavior cannot be read off from the components alone. A system is more than the sum of its parts because the parts interact.

Systems engineering, as a discipline, takes this seriously. Its subject matter is not the components but the interfaces—the contracts between subsystems, the emergent properties that arise from interaction, the failure modes that live in the gaps between parts. Systems engineers ask: what happens when component A does what it is supposed to do and component B does what it is supposed to do and they both do it at the same time? What happens when one of them does it slightly wrong, or does it at a speed nobody expected?

An electronics engineer understands the components. A software engineer understands the logic. A systems engineer understands what happens when they meet. This is not a hierarchy of sophistication; it is a question of where you are standing when you look at the problem. The background in electronics is not an embarrassment to a software career. It is an unusually direct route to understanding why the software-hardware interface is where the interesting problems live—avionics, medical devices, industrial control, embedded systems, the entire world where a logic error in code produces a physical consequence. That gap is where systems engineering was invented, because in those domains you cannot afford to let the permissiveness of software meet the consequences of the physical world without imposing discipline at every layer.

Nancy Leveson’s Engineering a Safer World demonstrates how systems thinking applies to safety-critical software. Her STAMP methodology forces engineers to consider not just individual components but the interactions between them, the information that flows between them, the feedback loops, the moments where intention diverges from execution. This is what engineering looks like when the stakes are physical.

IV. What “real” engineering requires

The anxiety about whether software “counts” as engineering is partly about rigor and partly about stakes. Civil engineering has a body of law, certification requirements, professional liability. When a bridge fails, there is a physical investigation, a forensic analysis, a career-ending reckoning. When software fails, the patch ships on Tuesday.

The safety-critical world imposes the rigor that general software does not: DO-178C for avionics software, IEC 62443 for industrial control, ISO 26262 for automotive. These standards are as demanding as anything in classical engineering, precisely because the embedded software is controlling physical systems and the consequences of failure are physical. You cannot ship a patch to an aircraft in flight. You cannot push a hotfix to a power plant. The discipline exists; it is just not universal. It appears precisely where the permissiveness of software meets the unforgiving nature of the physical world.

This is the honest answer to whether software engineering is real engineering: sometimes yes, sometimes less so, depending on whether the practitioners have chosen—or been required—to impose external constraints on an inherently permissive medium. The moment stakes become real, the rigor appears. The moment you stop counting, the slack returns.

V. The identity resolution

The electronics-to-software move is not a switch between disciplines. It is a move along an axis of abstraction while retaining the same underlying concern: designing systems that do not collapse under their own complexity. The engineer leaving behind Ohm’s Law is not leaving behind engineering. They are learning to impose discipline in a domain where the material refuses to do it.

What changes is what “collapse” means. In electronics, it means the circuit fails to carry current as designed. In software, it means the state space becomes unnavigable, the codebase becomes unmaintainable, the system fails in ways nobody anticipated because the interaction patterns were too complex to reason about. In systems engineering, it means the emergent behavior of the whole diverges from the intended behavior because nobody modeled the interactions correctly.

The engineer who has worked in all three registers—physical, logical, systemic—has not abandoned rigor by moving from the laws of nature to the laws of their own making. They have learned to live in a domain where there is no material to object, where every constraint is self-imposed, where the cost of being wrong compounds slowly until suddenly the entire structure is too tangled to untangle. That is harder, not easier. The discomfort is appropriate.

In Airplane! (1980), Johnny stands in the control tower during a desperate night landing—weather closing in, pilot struggling, runway dark. He reaches over and unplugs the cable controlling the runway lights. The blackout is complete. Everyone panics. And then he plugs it back in, smiles at the camera, and says: “Just kidding!” The joke lands because the constraint is so fragile, so dependent on one person’s decision not to pull the plug. In Watchmen (2009), the Comedian realizes the deeper truth: “It’s all a joke. It’s all a gag.” His character decides that in a world where the rules are made up and can be broken at any moment, the only sane response is to become a parody of society itself. Both moments reveal the same vertigo: systems built on permissiveness, held together by nothing but the collective agreement not to pull the plug. The engineer’s discomfort is the correct response to that knowledge. The material world enforces its own rules. We do not.

Further reading