And I think software companies should give a team the opportunity to invest time to know more about the subject.
For example when you write WMS software you should go to a warehouse and see what is going on, talk to the people who work there and understand why things are the way they are.
Because there is a huge difference between knowing that 1+1=2 and knowing why 1+1=2.
I've worked on both sides of enterprise software, firstly building and deploying Incredible Feats of Engineering in the face of Ludicrous Requests from the Idiot Clients, and then secondly as an actual front line worker, doing Work That Actually Matters in the face of ill-designed Utterly Broken Tools produced by Arrogant Engineers.
It's convinced me that "requirements gathering" in all it's forms just doesn't work, or at least is a currently unsolved problem.
If I ever set up a company it will be a kind of Gonzo software consultancy where my engineers take on long contracts, the first year at least of which is just working entry level in the client company, actually carrying their actual workload, actually reporting up their chain of command. The only way anything is ever solved properly is when someone who genuinely understands and needs to solve the problem, also has the skills to do it. The current system of promoting talent away from real problems splits these two things up.
I suspect a swing back towards in-house software development might become more attractive to decision makers, as big companies' boards of directors cotton onto the "Software Eats the World" trend, then panic-build before they're eaten by a competitor who got there first. AWS is just the beginning of what I suspect will turn out to be a marathon we're entering that even our great-grandchildren will run.
> Because there is a huge difference between knowing that the sky is blue and knowing why the sky is blue.
You might know it's 3.14... but not why.