We describe our processes and software products as having “security” or “reliability” or “high availability” but none of those are testable qualities, which is at the core of what the author is contending.

“F = m x a” is testable. If it were found to be untrue in some circumstances we could reproduce that untruth - and maybe uncover some new physics.

The measures I mentioned (security, reliability, high availability) don’t have clear failure points that multiple people can agree upon. Even if they did there’s nothing universal about those agreements therefore they have no value to a new project.

There is however something in the “meta” because utter disasters of software projects are less common (as a percentage of the number of projects in the world) than they used to be. We are learning axioms like “use of memory safe programming languages reduces human errors and that leads to safer code.”

There’s engineering, craftsmanship, and heuristics in every software engineering role. And all three exist in every project - sometimes even in every task!

We would all love to say it’s one or the other but it’s both.

Ok, when is it one and when is it the other?

Sorry to say it but we can’t even draw a line between CRUD database fetching business apps, and engineering the database itself. There’s no line - it is fuzzy and depends on the constraints your project faces.

Software engineering as we do it in 2025, is both UFOlogy and engineering. It’s one then it’s the other, at different times, with no clear distinction between the two. And sometimes a task you’re doing can even contain both types of work at once.