Is it possible the vast majority of decisions, preferences, best practices and so on are subjective?
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.
> 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?
(Those number are clearly made up, but illustrate the point.)
1. What should I do right now to solve this problem?
2. What will I wish one year from now that I had done to solve this problem?
The first one is relatively easy and won't see much debate. It's the second one which is complicated and the reason for debates usually, because you have to predict the future. All bets are off when you try to predict the future, nobody can do it. The best we can do is to let wise old men take the decisions with the hope that they have seen enough little more of the past and that the past sometimes repeats itself.
If I walk into a room and someone asks "how do I deploy this app to the edge" there's 1000 answers that will either be right or wrong depending on decisions about that apps design that were made long ago but will still impact how I have to deploy it.
It's still a very young field, in addition to being a moving target, so maybe it's too early for it to be formalized like more traditional engineering disciplines.
It doesn't mean that you should stop reading books or case studies, start ignoring industry best practices, or disregard your own professional experience.
generally there are requirements that you need to meet, constraints that you need to work with and known anti-patterns to avoid but there's a lot of freedom in the implementation