When Software Engineering Became a Humanities Degree

The Exam That Taught Me the Wrong Lesson

I studied computer science with a minor in sociology. My worst grades were in sociology, and it took me years to understand why.

The exams were multiple choice. Four or five options, and the wording between them varied so little that the meaning barely changed from one to the next. But one was correct and the rest were wrong. What the test measured was not whether you understood how societies work. It was whether you could tell, at the level of individual words, which sociologist a sentence belonged to.

This is not sociology failing at science. It is the humanities being the humanities: a different discipline, with a different test, or rather without the sciences’ test at all. Nothing external settles the argument; you cannot run the experiment that proves one thinker right and the next one wrong. So the thing you actually master is the map: which school holds what, where two thinkers part ways, how to place a sentence at the level of a single word. The models are partial, each one works only sometimes, and the craft is telling them apart. It is real intellectual work. But it is a craft of distinguishing between models, not of producing thought: you learn to separate other people’s ideas with razor-sharp precision, without ever being asked to add one of your own.

I bring this up because software engineering used to be the opposite. And it is quietly becoming the same thing.

Software Had One Hard Question

Your code has to work. That was the criterion. Ideally fast, ideally secure, depending on what you were building. But underneath everything sat a test that reality ran for you: it works, or it doesn’t. You could be junior, arrogant, self-taught, hard to be around; it didn’t matter. The compiler and the 3 a.m. incident did not care about your reputation. First principles, checked against the world.

Then we started proclaiming design patterns and “clean code.” Not as tools but as virtue. On the premise, never actually proven, that following these rules produces better maintainability and fewer defects. Maybe it does. Sometimes it does. But notice what happened to the criterion: it stopped being “does it work” and became “did you implement it the way the book says.”

That is a different kind of question. It has a canon. It has schools. It has people who can quote Uncle Bob chapter and verse and tell you your perfectly working function is wrong because it has four parameters instead of three. The measure moved from the world into the text.

Cargo Cult, Named in 2000

Steve McConnell saw this coming a quarter of a century ago. In IEEE Software in 2000 he borrowed Richard Feynman’s “cargo cult science” and coined cargo cult software engineering: organizations that imitate the visible forms of successful teams (the processes, the patterns, the meetings) without understanding why those forms ever worked for anyone. The tell, McConnell wrote, is the justification: “we’ve always done it this way,” or “our standards require it.” Reasons that point at a rulebook instead of a result.

That is the whole disease in one sentence. When you can no longer defend a practice by what it delivers, only by what the rules demand, you have left engineering and entered scripture.

Then Agile Turned “Get It Done” Into a Ceremony

I’ve written before about velocity theater, so I’ll be quick. Agile began as a correction: ship working software, get feedback fast. Then the industry ate it. The standup became a status ritual. The retro became a therapy hour. Story points became a currency nobody can convert into money or time. SAFe turned the whole thing into an org chart. The manifesto became a religion, and the certification industry became its church, selling indulgences two days at a time.

And a subtler shift rode in with it: the goal moved, quietly, from does the work ship to how does everyone feel about the work. Those are not the same question. Both matter, but only one of them is the job.

The Comfortable-and-Wrong Problem

Here is where it gets unpopular. The dominant advice is to remove the “brilliant jerk” to protect the team’s psychological safety. Sometimes that is exactly right; nobody does their best work in a room they are afraid of, and talent is not a licence to be cruel.

But a culture that optimizes only for comfort has a failure mode nobody likes to name: it protects the person who is pleasant and wrong over the person who is difficult and right. It rewards fitting in over being correct. And the one criterion that used to settle every argument, does it work, is exactly the one that makes people uncomfortable, because it can prove them wrong in public.

You can insist on basic decency and still keep the hard question first. The filter that matters is: are you right, and do you deliver. “Easy to sit next to” comes second. Invert that order, and you are optimizing a sociology seminar, not an engineering team.

The Cleanest Natural Experiment in the Industry

You don’t have to argue this in the abstract. The car industry ran the experiment for us.

Volkswagen built CARIAD in 2020 to win the software-defined car. By its own numbers it has been a disaster: operating losses reported north of $7.5 billion in three years, its 1.2 software platform delayed by 16 to 18 months and holding up the Porsche Macan and Audi Q6 e-tron, the next platform pushed toward 2027 or 2028. A McKinsey review commissioned inside the group reportedly found a dozen problems, chief among them that the various parties simply could not communicate with each other. Meetings, PowerPoint, org structure, legacy load: the full ceremony.

Tesla, across town, is the software-first company everyone else is now chasing. Flat, results-obsessed, indifferent to the ritual. You can dislike a great deal about how it is run and still see the pattern: the organization that kept asking “does it ship, does it work” outran the one that got very good at process. The productivity gap is a first-principles gap, not a rituals gap.

The Ceremony Comes for AI Too

Agentic coding is a real jump in productivity. We see it every day; the agent writes, the human orchestrates, and the throughput is not subtle.

The ceremony is already forming around it. “AI governance committees” and “prompt governance” are real, named things now: approval gates, prompt versioning and auditing, controls mapped to the EU AI Act and ISO 42001, and prompt-engineering certificates to collect. Some of this is genuinely necessary: security and compliance are not optional. But the same reflex runs underneath: turn a capability into a process, the process into a committee, the committee into a certificate. Reports already describe organizations that spent months building AI-governance frameworks only to find that nothing actually changed.

Stack enough of that on top of a 3x and you are back to 1x, with more meetings. The productivity is real; the appetite to bureaucratize it away is real too, and better funded.

The only defense is the old question, asked relentlessly: does the thing work, is it fast, is it secure, did it ship? Everything that cannot justify itself against that is ceremony, however reasonable it sounds.

What We Actually Do

This is why our Hard-Agile is a refusal rather than a methodology with a logo. We measure throughput, cycle time and flow (what ships and how fast) because those are the numbers reality checks, not the ones a team hands itself. We are not here to run your rituals or grade your patterns. We are here to make the thing work, make it fast, and leave when your team can keep it that way.

Software was never meant to be a humanities degree. It had the rarest thing a field can have: a hard, honest, external test of whether you were right. That is worth defending. Everything else is interpretation.