> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.
Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.
My problem with such articles is that they mix the creation of software with the servicing of the software. It can be pretty complex to serve sophisticated software at scale in a cost-competitive and secure manner and it will remain so. So the engineering will remain important and domain expertise will remain important as well, as it has always been. Different business will rely on different combinations of these to create their own specific moats.
I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles(https://agilemanifesto.org/). Values are not right or wrong, they are just values you agree to or don't.
The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called process experts under pressure from management which does not know any better. The authors of Agile Manifesto have frequently said the concept of Agile has been badly twisted.
The actual post and this comment shows how early we are when simple and obvious ideas look novel when first conceptualizing them. Nothing against these ideas though, they are indeed good.
It seems that the cause of the difference in opinion is that the anti camp is looking at the current state while the pro camp looking at the slope and projecting it into the future.
The advice is not bad, just tailored towards someone looking for a good stable boring job, which is all ok. Therefore the chaos of startups is highlighted as a red flag. Might be good to add here that there are good learnings in the chaos of startups as well, for particular people, at particular times.
(Good) Apps take the context of the user and their use-case from their head and make it into something the user can see and interact with. An app might or might not be the 'product'. Unfortunately it seems there is always going to be some 'product' so dark patterns might be here to stay.
At some point the model providers will realize they don't need to provide apps, just enterprise-grade intelligence at scale in a pipe, much like utility companies providing electricity/water. Right now, they have to provide the apps to kick-off the adoption.