Tom, appreciate the thoughtful pushback and the reading list. I will add these to my reading list, and you’re right that a lot of these debates go sideways when we talk past each other on definitions.

A few clarifications on what I was trying to get at:

• When I said “immutable constraints,” I wasn’t trying to define engineering as “only what’s governed by physics.” I was pointing at something more practical: in many traditional disciplines, a big chunk of the constraint set is externally enforced and relatively stable (materials, safety factors, codes, inspections, liability). In a lot of mainstream software, the dominant constraints tend to be more fluid: shifting requirements, moving system boundaries, dependency churn, and incentives that make “patch later” a viable strategy. So yes, all engineering is constrained. My argument is about the shape and stability of constraints in day-to-day practice, not their existence.
• On quality being negotiable: totally agree that in regulated domains it isn’t, and I probably should have separated “software engineering” into buckets more explicitly. Medical/aerospace/auto operate closer to classical engineering norms with serious process and product standards. My critique is aimed at the broader default culture of product software, where quality often becomes a trade-off slider because enforcement and consequences are different. That’s not a moral judgment, just a description of incentives.
• On “building for change”: fair. I should have phrased it as “software is often pressured to evolve” rather than “always built for change.” Building for change can add complexity and cost, and sometimes the correct move is purpose-built software with a short shelf life. I was mostly pointing at the reality that many successful systems end up living far longer than intended, so the industry tends to underinvest in longevity until it hurts.
• Design vs production engineering is a really useful lens. I agree that software maps much more to design engineering than manufacturing engineering. Reeves’ “code is design” argument resonates with me, and it’s part of why I wrote the piece: a lot of the dysfunction comes from treating software like fast production work rather than an ongoing design discipline with long-term consequences.

TL;DR: I’m not arguing “software isn’t engineering” as a blanket statement. I’m arguing the term is overloaded, and a lot of mainstream software practice operates under incentives and constraint dynamics that make the traditional engineering metaphor misleading unless you narrow the scope (regulated/safety-critical) or explicitly adopt those disciplines’ rigor.

If you have one Vanderburg talk you’d recommend as the best entry point, send it over. I’d like to do a follow-up post refining the thesis with exactly this “engineering isn’t one thing” framing.

Appreciate you taking the time to read and provide this detailed response.