Ask HN: Are most software engineering decisions subjective?
11 comments
Yes, because each decision is based on a previous decision, often made by someone else. Sometimes, someone 5 steps back made an awful decision which necessitates making another decision that may also be wrong, but wrong in a way that could leave the next person able to make a correct one.
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.
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.
The field which adopted methodologies like Agile, Scrum, and SAFe is clearly not an exact science, nor an engineering. It's more similar to "soft" sciences like for example social sciences.
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.
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.
yes, in the same way architectural building decisions are subjective. It would be bad to design an office building if you were supposed to design a school, and it would be bad to only have one door to a school and no windows, etc. Does it matter if you use bricks or steel or aluminum or glass or concrete for the exterior? Not as much.
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
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
Kind of - Suppose there are 100 ways to do a thing -- 80 of them will be wrong, 15 of them would work but have some problems, and 5 would work perfectly fine. Throwing out the 80 is science. Throwing out the next 15 is experience. Choosing amongst the remaining 5 is totally subjective.
(Those number are clearly made up, but illustrate the point.)
(Those number are clearly made up, but illustrate the point.)
Yes! All decisions are subjective. I do not think it is exclusive to software engineering, let engineering alone. There are two questions you can ask about any decision.
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.
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.
Yes, because the phrase "software engineering" is just a euphemism.
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.
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.
You should read this: https://hillelwayne.com/post/are-we-really-engineers/
Something that piqued my interest in that post:
> 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?
> 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?
I've heard computer science described as "applied mathematics". And if mathematics is a branch of philosophy, then perhaps software engineering is a distant branch (or the most cutting-edge frontier) of "applied philosophy".
Obligatory xkcd: https://xkcd.com/435/ (Although apparently Randall forgot to include philosophy in the chart.)
I agree with the software is grown analogy. And like gardening, many organizations get burned because they don’t adequately tend to the garden after it’s planted.
Is it possible the vast majority of decisions, preferences, best practices and so on are subjective?