> The confusion here comes from our misunderstanding of mathematics. Much of the math that mechanical engineers use is continuous math. This is where we work over a continuous domain, like real numbers. Things like calculus, trigonometry, and differential equations are in this category. This is what most people in the US learn in high school, codifying it as what they think of as “math”.
> In software, we don’t use these things, leading to the conception that we don’t use math. But we actually use discrete math, where we deal exclusively with non-continuous numbers. This includes things like graph theory, logic, and combinatorics. You might not realize that you are using these, but you do. They’re just so internalized in software that we don’t see them as math! In fact most of computer science is viewable as a branch of mathematics. Every time you simplify a conditional or work through the performance complexity of an algorithm, you are using math. Just because there are no integrals doesn’t mean we are mathless.
I'd be interested to hear more about this. What actually defines "math" then?
As a discipline and an industry, we don't have (or use even if we had) objective measures for things like code complexity, effectiveness of design patterns, when we should use or not use them. Like in the arts, some scientific and mathematical concepts are useful, and in fact form the foundation of software - but what we do is definitely not a science, and not engineering.
It's also an unresolved question whether "engineering" is the right approach to software development.
IMO, most successful software projects are "grown", and only in a lesser sense designed or engineered. And many projects fail due to being "over-engineered", whatever that means - but we know it when we see it.