In the simplest example: if you ship a car with a bug in its RTOS, people could die. It doesn't matter how easy it is to update. As a culture we’re generally opposed to preventable deaths. In other professions we have set up a regime of legal liability and professional licensing as guardrails and incentives to prevent that failure mode. We should treat software engineering the same, at a minimum in applications where lives are at stake.
Other non-lethal failure modes should also be considered (Experian, anyone?). We may have culturally decided by default or accident that data leaks are no big deal. If we actually did think they were important, it would make sense to have licensing and liability frameworks to reflect that.
The fact that software has fewer practical constraints than building structures is an excuse masquerading as a reason for not having even the most basic controls in place.
Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both.
The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because
1) automotive manufacturers don't fall under engineering firm regulations
2) one person cannot have meaningful technical oversight over the scope of a vehicle, and
3) there is no software PE accreditation process in the US.
The duration of the status quo doesn’t feel at all relevant to my argument.
> what is it about software that you think it should require a PE stamp when hardware should not?
Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice.
The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later.
I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.
In that case the requirement changed, it might require some extra support or upgrades to the bridge, if not we have to build the bridge all over again.
Similar in SWE, the requirement can change, if you planned a small MYSQL database to hold 2 Stores transactions and then "oh well we will need to support 2000 Stores Transactions" you might try upgrade the server or start from zero on a AWS cloud instance that keep up.
In SWE you still have the big decisions than can impact people and budget, a bridge can collapse, so the autopilot software can make the car crash
To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer.
For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.
I think even if rigor required it's low you can think of a good solution for a problem, feature or product
Making a birdhouse isn't engineering, creating a new type of dwelling for birds might be.
The whole "seat warmers as a service" pops to mind
That's the whole idea of "Digital Engineering"
The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1].
So yeah, it's happening
[1]https://www.istaridigital.com/press-releases/air-force-award...
What I mean is imagine if a car company found a defect with their cars, they would have to issue a recall and update their vehicles, a long an expensive process. The key difference is with SWE, we can just push an update and have the thing fixed, there are many possible scenarios here but overall even if you had to push a patch to customers that are running in an air-gapped env, even that would be easier than a traditional recall in engineering. For me this single fact changes the entire dynamic of SWE compared to traditional engineering.
In traditional engineering you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road", but you can totally do that with SWE application that can only support X number of users at the start but plans to scale up to support more. This thinking of "we can address this down the road" affects practically every decision in SWE compared to traditional engineering outside of specific cases.
Every engineer deals with constraints and finds ways around those constraints. SWE has a set of constrains that is very very different from virtually all other engineering disciplines, and for that reason you get the constant question of whether SWE is even real engineering.