Software Engineering is the discipline that, in 1968, looked at the smoldering wreckage of every software project ever attempted and concluded that what it really needed was not better practices, better tools, or better understanding, but a better name. Specifically, someone else’s name. Specifically, the name of people who build bridges.
It has spent the subsequent fifty-eight years proving the metaphor wrong in every measurable way, while simultaneously insisting on keeping it.
“We called it engineering because ‘structured guessing’ tested poorly with management.”
— Apocryphal, but spiritually attributed to everyone at the 1968 NATO Conference
The Naming
In October 1968, a group of scientists, mathematicians, and industry representatives gathered in Garmisch, Germany, for the NATO Software Engineering Conference. The software crisis was in full bloom. Projects were late. Budgets were fiction. Programs crashed with the regularity and enthusiasm of a dog greeting its owner. Something had to be done.
What was done was a conference. And at the conference, what was done was a naming.
The word engineering was chosen deliberately. Not craft, which implied something artisanal and hand-woven and therefore not suitable for military budgets. Not science, which would have required reproducible results, a standard the field was not prepared to meet and has not met since. Not dark art, which while accurate would have raised questions during procurement. Engineering — because engineering implied rigour, predictability, mathematical foundations, and professional standards, and because the people in the room very much wanted all of those things and believed that naming them was the first step toward having them.
It was not.
“Naming a thing does not make it that thing. I can call a potato a satellite, but it will not orbit the Earth. Although — give me enough velocity and a lack of regulatory oversight — never mind.”
— The Caffeinated Squirrel, derailing a planning meeting
The Gap
The gap between the name “software engineering” and the practice of software engineering is the gap between a load-bearing calculation and “it works on my machine.”
Consider the differences:
Civil engineers have physics. The load a bridge can bear is calculable. The tensile strength of steel is known. The equations are settled. A bridge either holds or it doesn’t, and the math tells you which before you build it.
Software engineers have Stack Overflow. The load a system can bear is theoretically calculable and practically unknowable until the moment it falls over in production at 3 AM, at which point the engineer who built it has left the company, the documentation was “the code is self-documenting” (it was not), and the only person who understands the deployment pipeline is on holiday in a country with no cellular coverage.
Civil engineers test materials before construction. They know the properties of concrete, steel, and wood. The materials do not change their properties based on the time of day, the operating system, or whether Mercury is in retrograde.
Software engineers build on dependencies that update themselves at 2 AM, silently changing their behaviour in ways that are technically documented in a CHANGELOG that no one reads because it is four thousand lines long and begins with “BREAKING:” in a font size that suggests the author was screaming.
Civil engineers can look at a bridge and tell you if it will stand.
Software engineers can look at a codebase and tell you “it depends.”
The Certifications Nobody Asks For
In many countries, you cannot call yourself a civil engineer without a professional license. You must pass examinations. You must demonstrate competence. You must carry insurance against the possibility that your bridge kills someone, which is a powerful motivator for correctness.
In software, certifications exist. They are produced by organizations with acronyms. They require study, examination, and fees. They certify that you have studied for, been examined on, and paid fees for the certification. Employers occasionally list them in job postings, in the same section as “nice to have” and “ping pong table,” and with approximately the same weight.
The industry’s actual credentialing system is the technical interview, which has evolved into a ritual so disconnected from the actual work that anthropologists have begun studying it as a form of hazing.
The Whiteboard Tribunal
To become a software engineer — that is, to be hired as one — you must pass the Whiteboard Tribunal. This is a process in which a candidate is placed in a room, given a marker, and asked to implement a red-black tree from memory, or to determine the optimal algorithm for a problem that the interviewing company does not have and will never have, while three to five engineers watch in silence, occasionally nodding in a way that conveys nothing.
The candidate’s actual job, should they be hired, will involve:
- Reading JSON
- Moving JSON from one place to another place
- Arguing about whether the JSON should be camelCase or snake_case
- Attending meetings about the JSON
- Writing tests for the JSON (optional, aspirational)
- Debugging why the JSON is wrong at 3 AM (mandatory, recurring)
At no point will the candidate reverse a linked list, balance a binary tree, or implement Dijkstra’s algorithm. The interview tested none of the skills the job requires, and all of the skills the job doesn’t. This is considered normal. This is the industry’s entrance exam, and it is the equivalent of requiring aspiring chefs to prove they can juggle before allowing them near a kitchen.
“I was once asked to implement a B-tree on a whiteboard. My actual job was moving database rows from one table to a slightly different table. I could have trained a pigeon to do my actual job. The pigeon would have failed the interview.”
— Anonymous, r/ExperiencedDevs
The Ceremony Industrial Complex
riclib, having spent years as a consultant observing enterprises from the inside, has documented a phenomenon he calls the Ceremony-Engineering Confusion: the tendency of large organisations to mistake process for engineering.
The reasoning runs as follows: Real engineering has processes. Therefore, more processes equal more engineering. If we add enough standups, retrospectives, sprint plannings, backlog groomings, architecture review boards, change advisory boards, and bi-weekly alignment syncs, we will eventually achieve engineering.
This is like believing that if you attend enough funerals, you will eventually understand death.
What riclib observed, across dozens of enterprises and hundreds of teams, was consistent: the organisations with the most ceremony produced the least software. The teams that shipped were invariably the ones that had found ways to route around the process — small groups of people who met informally, made decisions quickly, and wrote code while the official process was still debating the ticket format.
“I watched a team spend six weeks defining their Definition of Done. They had not, during those six weeks, done anything. The Definition of Done was the only thing they’d done, and by its own criteria, it wasn’t done.”
— riclib, consulting notes, 2019
The enterprise had confused the map for the territory, the menu for the meal, and the Jira board for the software.
The Caffeinated Squirrel’s Proposal
When presented with the observation that software engineering is not, in fact, engineering, The Caffeinated Squirrel proposed a solution that was, characteristically, the exact wrong lesson to draw.
“You’re saying we’re not rigorous enough? FINE. I’ll show you rigorous. I’m going to build a software forge. A LITERAL forge. Every commit must be load-tested against a mathematical proof of correctness. Every pull request requires three independent formal verifications. Every deployment must be signed by a licensed Professional Software Engineer — I’ll create the licensing body, I’ve already registered the domain — and every standup will be replaced by a load-bearing ceremony in which each developer must physically support the weight of their technical debt. I’ve calculated the average at forty-seven kilograms. We’ll need a gym.”
— The Caffeinated Squirrel, vibrating at a frequency that concerned the structural engineers in the adjacent office
The proposal was six hundred pages long. It included a certification exam, a licensing board, a code of ethics, a physical fitness requirement, and a pension scheme. It was the most over-engineered solution to over-engineering ever conceived, which was either ironic or inevitable, depending on your tolerance for recursion.
The Lizard’s Assessment
The Lizard, when asked whether software engineering is really engineering, blinked once and said:
“No.”
A pause.
“But it works. Bridges don’t evolve. Software does. Stop comparing.”
This is, in eleven words, the most accurate assessment of the field ever produced. The Lizard then returned to its rock and declined all follow-up questions, which is the correct number of follow-up questions to accept on the topic.
The Actual State of Things
Software engineering is not engineering in the way that civil engineering is engineering. It is also not not engineering. It exists in a quantum superposition between rigorous discipline and creative chaos, and it collapses into one or the other depending on whether a deadline is present.
What it actually is, beneath the name and the certifications and the whiteboard interviews and the ceremonies, is this: a group of people trying to build things that work, using tools that change every eighteen months, on platforms that deprecate every thirty-six months, for users who will find the one path through the application that no one tested, every single time, without fail, forever.
That this works at all is not a testament to engineering. It is a testament to stubbornness, caffeine, and the quiet heroism of people who fix things at 3 AM because they care, not because their license requires it.
Measured Characteristics
Year "engineering" was borrowed: 1968
Years spent justifying the name: 58 and counting
Bridges built by software engineers: 0
Bridges crashed by software engineers: several (metaphorical)
Professional licenses required to ship to prod: 0
Professional licenses that exist: several (decorative)
Whiteboard interviews that reflect actual work: ~0%
Actual work that involves reversing linked lists: ~0%
Salary for moving JSON between services: $200,000 (SF, 2026)
Salary for building actual bridges: less (unfair, documented)
Methodologies tried: all of them
Methodologies that fixed everything: none of them
Projects delivered on time and on budget: classified
"It works on my machine" (daily global occurrences): ~2.4 million
Stack Overflow mass: load-bearing
The Squirrel's licensing proposal (pages): 600
The Lizard's assessment (words): 11
Lines of code in utils.js: do not ask
Last person who touched utils.js: left the company
See Also
- YAGNI — The principle software engineers preach and violate in the same breath
- Ceremony — What enterprises do instead of engineering
- The Demo Effect — When even the name “engineering” cannot save you
- Technical Debt — The load-bearing calculation software engineering actually needs
- Debugging the Void — What happens when you engineer things that didn’t need engineering
- Confidence — Required to call yourself an engineer; destroyed by the job
