[Verdex]

While I like the idea of something that helps software engineers to make the right decision due to simply self preservation (so we'll reach even the most self centered software engineer), I don't think Professional Engineering licenses are going to be able to help.

If you're designing a bridge, this is pretty obvious work and it's pretty isolated. What I mean by that is that A) you're not going to go off and design bridges in secret and then sell those designs to someone who will build it in secret such that the public will later make use of the bridge. At some point someone in the government is going to ask why there's a new bridge over that river. And B) there isn't a huge world wide market for bridges that has near infinite sub niches in nearly every market imaginable.

So having a professional engineer license for bridges makes sense because if the license is lost, then it really does mean the end of your career.

Software is often an engineering artifact, but it's also like mathematics. And it's also like literature. You might be able to stop someone from selling their services directly, but you can't stop them from writing code altogether without forming a terrifying oppressive distopia.

So the Professional Software Engineer might not care about losing the license because they can still sell their skills to companies on the other side of the world where there is no regulation. Or they can create their own product that contains software and sell that product. Or they can publish their software on github and somehow make enough from tips that they don't need another job. Or they can get a job that doesn't require software development but can be highly augmented by it. Or they can make websites technologically unsophisticated users.

Losing the license doesn't mean that their career is over. It is only a slight annoyance. There's always going to be enough software engineers that aren't afraid of losing a license that the ones that are afraid won't prevent anything problematic from happening.

[snowwindwaves]

I write software that controls hydro electric power plants including spillways and sluice gates and complying with environmental license etc. nobody has ever asked to look at the control system programs which take me the better part of a year to complete, starting from a library of about 50 different completed power plant control systems, so I am generally not doing much creative work just adapting and re-use of existing components and design patterns.

There are 10,000 virtual wires in the PLC that nobody cares about excepT for me and my coworkers in the same role, but the 30-40 physical relays and 1000 physical conductors in the power plant represented on schematics are reviewed by the customer and stamped by a Professional Engineer, because everyone understands they are expensive to change later.

Customers don't want to pay the additional cost to have their software stamped. They don't want to be told I can't fix that mechanical or civil design flaw in software because I don't want to open myself up to be liable for trying to help the customer get or keep their plant running despite some problems wiTh equipment supplied by others. People have this idea that software is easy to change. We can fix that later! Why decide now? It is a battle to arrive at the plant wiTh a complete, tested, documented control system, commission it and then shut the door and walk away. I have to be a really insistent about getting the information require to really complete my deliverables and then be very particular when other people's designs don't match what they delivered or work as intended. It is counter to my nature of wanting to solve problems instead of creating them or passing the buck, but that is what is required.

[bumby]

Do you feel like this is changing? In a different comment I noted how controls engineering is a more recent PE discipline and my (maybe optimistic) hope is that this is part of a larger trend to add rigor to the field.

Sometimes I feel like this is cave drawings compared to other more mature fields. But maybe that's what boilermakers felt like 150 years ago.

As an aside, how does one get into a field like yours?

[snowwindwaves]

controls engineering still mostly deals with the physics of the process and not how the software is implemented.

It is probably different on larger projects or when working for public utilities. All of the ones I have worked on are less than 50MW and are owned by corporations.

I think a lot of the automation field is learned on the job. you can take a PLC programming course but all you learn is the specifics of how to program that platform. It doesn't tell you what to program. That depends on the process you are controlling. I got in to hydro by working for a utility that owned a power plant as a student and then when looking for work after university sought out any opportunities for someone who liked programming and power plants. There are lots, but the catch is having the experience to get the job. I got in the door of a power plant by helping to program their datalogging and alerting system and then learned how to program the machines from a consultant who graciously provided me the on the job training and an owner who was willing to let me make mistakes.

[zwkrt]

Imagine you replaced "software" with "civil" and everything you said remains true. I can design bridges in my home but I can't sell my services legally. Will someone buy one of my bridge designs and impelement it, especially in another country? Possibly! But that doesn't make me a civil engineer, and no engineering firm would hire me. Also, it is probably cheaper and easier for people in other countries to hire a local engineer than to use my services anyway.

Your base assumption that other countries than <your country> would not have regulation might be true at first, but probably not for long, and something is better than nothing.

I agree that people cannot be banned from writing software outright, but I think it is reasonable that in many situations it is reasonable that a company or agency is held to a standard that they only deploy software that has been produced through some set of engineering practices, similar to GAAP.

[Verdex]

> Imagine you replaced "software" with "civil" and everything you said remains true.

This is false. Bridges are large and have failure cases that managers and government officials understand.

Software is invisible and has failure cases that are completely incomprehensible.

Hiring a bridge designer from another country who is really keen on avoiding the background check will raise some eyebrows.

Hiring a nearly anonymous software engineer from who knows where is business as usual for many large companies.

Bridges have pretty limited use cases. There really isn't that many places to hide if your banned.

Software is in everything. Software is used by everyone. Right now it's big enough that people can make it through an entire career without actually knowing how to program (just make sure you move jobs every few years). It's only going to get bigger. Losing a license just means that it's time to job hop again. Maybe shift gears and become a process consultant. Losing a license in software is not a deterrent.

> something is better than nothing

We have a lot techniques to evaluate what a good way is to build a bridge. Right now with software the best thing we have is code smells. It just smells bad to me. We have no ability to objectively encode what makes code good or bad. We just "know it when we see it". Something can most definitely be MUCH worse than nothing.

[exelius]

> This is false. Bridges are large and have failure cases that managers and government officials understand.

They only think they understand.

> Software is invisible and has failure cases that are completely incomprehensible.

Which are becoming increasingly comprehensible with better tooling and data collection.

> Hiring a bridge designer from another country who is really keen on avoiding the background check will raise some eyebrows.

It does in software too; at least with serious companies.

> Hiring a nearly anonymous software engineer from who knows where is business as usual for many large companies.

These typically come through staffing companies because most large companies are awful at hiring technical talent. They have a long-term relationship with the staffing company and expect the staffing company to ensure the competency of the workers. I actually think licensing software developers would put an end to this; as it would give HR departments a relatively high-fidelity signal to sort the professionals from the hobbyists (by far the hardest thing for a non-technical person to do in hiring developers IMO).

> Maybe shift gears and become a process consultant. Losing a license in software is not a deterrent.

"Processes" are rapidly converging into off-the-shelf SaaS products, and the industry is actually starting to slow down quite a bit. Trust me, the Big 4 and similar management consulting firms are in for a world of hurt over the next 5 years as AWS, GCP and Azure start to hone in on the ERP systems and reference process space. Companies today would rather spend $1M and 2 months to implement a non-customized, off-the-shelf solution that can be maintained by cheap offshore resources than spend $30M and 2 years to build something custom that requires a dedicated support and maintenance team. Maybe there's some vendor selection and strategy up front, but all those companies that used to do process consulting just become system integrators (for guess what -- software!)

[AstralStorm]

We have one big thing that shows the code has quality or lacks it. Number and severity of defects. You can normalize it by dividing over number of features supplied.

This data is generally fudged and hidden though by management in closed software products as well as being mislabeled.

And finally, users are not informed on how to report software issues and trained to normalize deviance - ignore problems and apply workaround.

[stickfigure]

Bridges and civil structures are permitted, with plans (and fees) filed with government offices. That's how licensing is enforced.

Imagine for a moment, a world in which every git commit requires a permit from the county planner.

Also: You will not get agreement on what the GAAP practices of software are. This industry isn't that mature.

[Verdex]

> Also: You will not get agreement on what the GAAP practices of software are. This industry isn't that mature.

Hear, hear.

This point cannot be overstated enough. People have been building bridges for thousands of years. Software Engineering has only really been a thing for a few dozen years. We do not know what we're doing yet and it's going to be a very long time before we do.

Different domains almost definitely need different guidelines. Different ways of thinking might even need different guidelines. Anything we try to enforce now will be seen as embarrassingly dangerous in the future on the order of using radium for wrist watches.

[lisper]

> People have been building bridges for thousands of years. Software Engineering has only really been a thing for a few dozen years.

Also, the cost of building a bridge is many orders of magnitude higher than the cost of designing it. The cost of producing software, by contrast, is almost entirely the cost of designing it. This matters. Legal regimes that don't respect the laws of economics (which are, after all, just corollaries of the laws of physics) are bound to fail.

[eeZah7Ux]

> Imagine for a moment, a world in which every git commit requires a permit from the county planner.

You are making a huge strawman.

[kaybe]

So... if I buy the land I need, can I just build a bridge over a river or do I need some kind of special permit? (Small streams are obviously ok since that is done a lot.)

[AstralStorm]

You might need city architect permit or equivalent and have to employ certified civil engineers by law.

[dsfyu404ed]

If your government respects personal property you can generally do what you want on your own land without permits as long as you don't make a business out of it.

[mcguire]

Bridges are not the only things Professional Engineers are involved with. Aviation manufacturers, who often do exactly the kinds of things you describe, have Designated Engineering Representatives (weirdly, not required to be a PE) who is responsible for signing off on the airworthiness of equipment.

Further, losing your license is not the only or the worst consequence. (https://scholarship.law.edu/cgi/viewcontent.cgi?article=3165...) You also assume a civil liability which would be hard to prosecute for a non-licensed software engineer.

(And yes, if the 737 MAX 8 thing is officially reported to have a significant engineering failure, some DER is going to have a very bad day.)

[fwip]

Even if 9 in 10 software engineers don't care, you only need one whistleblower.

[Verdex]

Mike: "Hey, boss. I think this stuff we're doing might be dangerous. I could even lose my license over it."

Boss: "You know Mike, I think you might be right. We'll get Ken and Joe to take a look at it and see if they can't figure out a way to make it safe. After all, they saved the day with the last big project."

Ken and Joe proceed to hack something together that's super dangerous. Mike is isolated such that he won't notice what's actually going on with his previous project and then never given another raise again.

For bonus points make sure to put your engineers on projects that you don't mind cancelling and then asking them to do something dangerous. Isolate the ones that seem nervous or raise objection and give bonuses to the ones that are fine with being reckless.

[thfuran]

Don't forget the last step: Delete all possible documentary evidence that you've willfully done this. Otherwise you're (probably) gonna have a bad time (eventually).

[Verdex]

Don't delete it. That only makes you look super guilty. And can get you in legal trouble if you start deleting after the trial begins.

The evidence shows that you cancel projects that Mike tells you are unsafe. And the record shows that Ken and Joe have a history of saving the day. "I had no idea that Ken and Joe were cutting corners. I'm not a software person, so I rely on my experts to tell me when things are unsafe. It's all Ken and Joe's fault."

[thfuran]

If there's evidence that you've been deleting things, you haven't deleted enough evidence.