This is a question I've struggled with ever since I started working in the field.
In terms of definition, software development ticks all the boxes - depending on who you ask.
Yet every way you look at it, something just doesn't feel right. Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom.
By "freedom" I strictly mean lack of limitations. While the laws of physics dictate what can and can't be done in traditional engineering disciplines, the same cannot be said about software.
A good design can be quantified, tested, and improved based on hard data (and eventual failure). A good program, however, is super hard to qualify. What even is "good maintainability" in terms of software? Is it a bunch of metrics like cyclomatic complexity, Halstead volume, and lines of code haphazardly cobbled together to form an arbitrary index value?
With traditional engineering you have material properties like tensile strength that you can match against requirements and safety margins. What's the equivalent of tensile strength of a software product and can we measure it?
For decades people in scientific computing have relied on Fortran programs that defy any modern notion of maintainability. The subroutines and "drivers" are limited to 6-character names and functions with >25 arguments are not uncommon.
Yet they still work, are still used and stood the test of time despite archaic properties [0], which require users to memorise large tables of codes for data types and routine names.
I also feel that despite these limitations, libraries like LAPACK are more readable and maintainable than modern C++ monstrosities like this [1].
[0] http://www.netlib.org/lapack/lug/node24.html
[1] https://github.com/nlohmann/json