Comment by no_wizard

> can’t think of another career where management continuously does not understand the realities of how something gets built

All engineering. Also all government and a striking amount of finance.

Actually, this might be a hallmark of any specialist field. Specialists interface with outsiders through a management layer necessarily less competent at the specialty than they are. (Since they’re devoting time and energy to non-specialty tasks.)

While product often does operate in a waterfall model, I think this is the wrong mindset. Good product management should adopt a lot of the same principles as software development. Form a testable hypothesis, work to get it into production and begin gathering data, then based on your findings determine what the next steps are and whether to adjust the implementation, consider the problem solved or try a different approach.

> I can’t think of another career where management continuously does not understand the realities of how something gets built.

This is in part a consequence of how young our field is.

The other comment pointing out other engineering is right here. The difference is that fields like Civil Engineering are millenia old. We know that Egyptian civil engineering was advanced and shockingly modern even 4.5 millenia ago. We've basically never stopped having qualified civil engineers around who could manage large civil engineering projects & companies.

Software Development in it's modern forms has it's start still in living memory. There simply weren't people to manage the young early software development firms as they grew, so management got imported from other industries.

And to say something controversial: Other engineering has another major reason why it's usually better understood. They're held to account when they kill people.

If you're engineering a building or most other things, you must meet safety standards. Where possible you are forced to prove you meet them. E.g. Cars.

You don't get to go "Well cars don't kill people, people kill people. If someone in our cars die when they're hit by a drunk driver, that's not our problem that's the drunkard's fault." No. Your car has to hold up to a certain level of crash safety, even if it's someone else who causes the accent, your engineering work damn better hold up.

In software, we just do not do this. The very notion of "Software kills people" is controversial. Treated as a joke, "of course it can't kill people, what are you on about?". Say, you neglect on your application's security. There's an exploit, a data breach, you leak your users' GPS location. A stalker uses the data to find and kill their victim.

In our field, the popular response is to go "Well we didn't kill the victim, the stalker did. It's not our problem.". This is on some level true; 'Twas the drunk driver who caused the car crash, not the car company. But that doesn't justify the car company selling unsafe cars, why should it justify us selling unsafe software? It may be but a single drop of blood, but it's still blood on our hands as well.

As it stands, we are fortunate enough that there haven't been incidents big enough to kill so many people that governments take action to forcibly change this mindset. It would be wise that Software Development takes up this accountability on it's own accord to prevent such a disaster.