Honestly, I think that most people are missing the real issue which is financial. And I apologize for the blow out but this topic really frustrates me and unfortunately very few are willing to acknowledge the issue.
In general, people and therefore developers as well, tend to put the minimum effort required to achieve a goal without much consideration into the future. Think about it. Where the industry imposes severe restrictions and quality standards, like for example buildings, the requirements by themselves elevate the good engineers. The requirements are also what keep non-relevant to the job people out of the industry or decision making paths. You can't have a linguist (no pun intended) who doesn't understand physics, drive the project management of building a bridge. For the same reason that you can't have a kindergarten teacher who doesn't like children or for the same reason that you can't have a nuclear factory engineer who don't understand nuclear physics. They are unsuitable and even dangerous.
But, with software and especially software that is not life or mission critical, we do. We have so many people that have not the necessary background, driving decisions and usually sacrificing quality for cost, even when the sacrifice means a shity output. We add and expect numbers over quality. Although DEVOPS is upon us, we still have in many places the business driving features with complete lack of understanding of the technical challenge and often don't even care. I'm not saying we shouldn't do difficult stuff, but the impact needs to be understood from all aspects, including if and whether the right people are there. When decisions are driven in the dark, then there is a problem. When the qualified people find themselves amond irrelevance they get worse because there is nothing to challenge them. And unfortunately, we are doing this more and more often. To be clear, the issue is not with training inexperienced people but with the potential and mindset compatibility or rather lack of it them which plague the industry.
I've got multiple examples and I think the situation is getting worse. With the tools improving, there is a general consensus that less skill is required to be a software engineer that is one of the best paying jobs. Anyone would "smell" the gold and would like to get in the party. And why not? Nobody is saying to them no! Instead we are even punishing the skilled and qualified ones by adding an extra burden without a return for the investment. As long as some managers could argue that they reduced the cost. Cost is important but would you remove the foundations of the building to cut cost? Would you live in that house? No but still in software we do these things. Another example is during hiring processes, where your skill and talent is impossible to convey because the managers and recruiters involved in the hiring are unable to evaluate your skill because they don't understand it. Anyone who wants to manipulate the system can get in and then we wonder where the problem is.
And yes, universities and schools adjust to this mindset. They get paid afterall to produce numbers without true quality gateways. People who would normally look down to the developers are going after this industry and why wouldn't they? They get paid well to do something that they don't really understand nor can they relate to. But they still get paid much better than other jobs.
And as a small reminder, similar things happened in the past as well. Anyone is old enough to remember why and how Visual Basic became so successful? Anyone is old enough to remember how people were hired in the DOTCOM era in the banks? I remember people getting hired at banks with really high salaries just because they could do an alert("Hello") with VBS because back then just mentioning the word code was frowned upon. Former colleagues of mine were biologists who got into the software engineering because they had a university degree. They turned out fine but I'm sure others didn't and are probably in the industry.
The immaterial nature of software makes it challenging but also a place were irrelevance is also dominant. This is THE elephant in the room and if you don't have any they you are really lucky and I do hope that you don't get to have one.
I think I agree with what I'm seeing of your point here.
Of course, the "financial"/traditional business sector has had relatively little to no bearing on FOSS over the past twenty+ years, so if it were primarily financial, these problems wouldn't be creeping into little indie dev-run projects too.
I know I've recommended it elsewhere in the thread, but check out "Dreaming in Code" by Scott Rosenberg. It speaks a lot to the hiccups in software development over the years, both in FOSS and proprietary sectors.
I assume you this is the book. Looks interesting but since I've read both The DEVOPS handbook and The Phoenix project I would like to ask you if you still recommend it and what would be different with these books. That is of course if you've read any of them. If you haven't, then they are a must.
I have read neither, but at a glance (yay Amazon) I can tell you that this isn't even remotely similar. Dreaming in Code isn't a technical book; it is a first-hand account of an actual FOSS project, from its inception to its first stable release, and all of the ups and downs along the way. Rosenberg also takes time to explain the history behind the various project management phenomenons the project experienced. In many ways, it reads more like a story than anything.
Honestly, I think that most people are missing the real issue which is financial. And I apologize for the blow out but this topic really frustrates me and unfortunately very few are willing to acknowledge the issue.
In general, people and therefore developers as well, tend to put the minimum effort required to achieve a goal without much consideration into the future. Think about it. Where the industry imposes severe restrictions and quality standards, like for example buildings, the requirements by themselves elevate the good engineers. The requirements are also what keep non-relevant to the job people out of the industry or decision making paths. You can't have a linguist (no pun intended) who doesn't understand physics, drive the project management of building a bridge. For the same reason that you can't have a kindergarten teacher who doesn't like children or for the same reason that you can't have a nuclear factory engineer who don't understand nuclear physics. They are unsuitable and even dangerous.
But, with software and especially software that is not life or mission critical, we do. We have so many people that have not the necessary background, driving decisions and usually sacrificing quality for cost, even when the sacrifice means a shity output. We add and expect numbers over quality. Although DEVOPS is upon us, we still have in many places the business driving features with complete lack of understanding of the technical challenge and often don't even care. I'm not saying we shouldn't do difficult stuff, but the impact needs to be understood from all aspects, including if and whether the right people are there. When decisions are driven in the dark, then there is a problem. When the qualified people find themselves amond irrelevance they get worse because there is nothing to challenge them. And unfortunately, we are doing this more and more often. To be clear, the issue is not with training inexperienced people but with the potential and mindset compatibility or rather lack of it them which plague the industry.
I've got multiple examples and I think the situation is getting worse. With the tools improving, there is a general consensus that less skill is required to be a software engineer that is one of the best paying jobs. Anyone would "smell" the gold and would like to get in the party. And why not? Nobody is saying to them no! Instead we are even punishing the skilled and qualified ones by adding an extra burden without a return for the investment. As long as some managers could argue that they reduced the cost. Cost is important but would you remove the foundations of the building to cut cost? Would you live in that house? No but still in software we do these things. Another example is during hiring processes, where your skill and talent is impossible to convey because the managers and recruiters involved in the hiring are unable to evaluate your skill because they don't understand it. Anyone who wants to manipulate the system can get in and then we wonder where the problem is.
And yes, universities and schools adjust to this mindset. They get paid afterall to produce numbers without true quality gateways. People who would normally look down to the developers are going after this industry and why wouldn't they? They get paid well to do something that they don't really understand nor can they relate to. But they still get paid much better than other jobs.
And as a small reminder, similar things happened in the past as well. Anyone is old enough to remember why and how Visual Basic became so successful? Anyone is old enough to remember how people were hired in the DOTCOM era in the banks? I remember people getting hired at banks with really high salaries just because they could do an
alert("Hello")with VBS because back then just mentioning the word code was frowned upon. Former colleagues of mine were biologists who got into the software engineering because they had a university degree. They turned out fine but I'm sure others didn't and are probably in the industry.The immaterial nature of software makes it challenging but also a place were irrelevance is also dominant. This is THE elephant in the room and if you don't have any they you are really lucky and I do hope that you don't get to have one.
I think I agree with what I'm seeing of your point here.
Of course, the "financial"/traditional business sector has had relatively little to no bearing on FOSS over the past twenty+ years, so if it were primarily financial, these problems wouldn't be creeping into little indie dev-run projects too.
I know I've recommended it elsewhere in the thread, but check out "Dreaming in Code" by Scott Rosenberg. It speaks a lot to the hiccups in software development over the years, both in FOSS and proprietary sectors.
I assume you this is the book. Looks interesting but since I've read both The DEVOPS handbook and The Phoenix project I would like to ask you if you still recommend it and what would be different with these books. That is of course if you've read any of them. If you haven't, then they are a must.
I have read neither, but at a glance (yay Amazon) I can tell you that this isn't even remotely similar. Dreaming in Code isn't a technical book; it is a first-hand account of an actual FOSS project, from its inception to its first stable release, and all of the ups and downs along the way. Rosenberg also takes time to explain the history behind the various project management phenomenons the project experienced. In many ways, it reads more like a story than anything.
In short, I definitely still recommend it.
Thanks