I’m a deep skeptic of “absolutism”.  And the use of “engineering” to describe software development breeds absolutism.

The word Engineering in other contexts is grounded in science.  As if there is one answer, or at least one best answer, to a scientific problem.  For example, mechanical engineering is bound by properties of the materials in use.

Whereas software development is about the art, not science, of using languages. While languages have rules, they also have flexibility.  Use of a language can be precise, obtuse and everything in between.

Lots of priorities can be served (or not) with a given program.  Want your code to be performant?  Want your code to be maintainable, as in understandable by others?  Want your code to be modular so that it can be easily refactored or replaced?  All will affect how the code is written.

If you doubt the flexibility of coding languages, then what can explain software quality assurance?  After all, these myriads of tests are to deal with the innate diversity, flexibility and expressiveness of code and of the coder.

And we haven’t even got to the choices in designing components of code and architectures.

So why does this matter?  Because thinking about software development in – pardon the word – binary terms ignores many of the choices and challenges of building great software products.  You might not care about things like “cyclomatic complexity”, but you will when you inherit someone else’s code from 10 years ago and you need to keep it going.

We need to focus on choices not absolutes; on degrees of truths.  Software has gotten too damned complicated to think of it in simplistic terms.

Maybe we should call developers “software linguists”?