There's no need to have software engineering be regulated. It'd be a restriction/deterrent at the wrong level.

In order to fix this we need the individuals in charge to be held legally accountable without hiding behind a corporation.

In the software industry management rarely ever listens to concerns brought up by engineering even if it's technical concerns.

Management not having to listen to engineers is the structural problem. How do managers know which concerns that engineers bring up are actually relevant? How do engineers know which concerns have real world consequences (without having a incredibly high burden of proof)?

Having regulation, or standardisation is a step toward producing a common language to express these problems and have them be taken seriously.

Leadership gets a strong signal - ignoring engineers surfacing regulated issues has large costs. Company might be sued and executives are criminally liable (if discovered to have known about the violation).

Engineering gets the authority and liability to sign off on things - the equivalent of “chartership” in regular fields with the same penalties. This gives them a strong personal reason to surface things.

It’s possible that this is harder for software engineering in its entirety, but there is definitely low hanging fruit (password storage and security etc).

> In the software industry management rarely ever listens to concerns brought up by engineering even if it's technical concerns.

Yet they have to listen to a Chartered Accountant or a Chartered Engineer. Maybe it would be as much in the engineers interest to have a professional body as it would for the public