Big E Engineering vs little e engineering.
IMO the barriers to entry are just much different, and it’s reflecting in the workforce. There’s cultural differences too, but I think the education differences is the biggest cause.
IMO the barriers to entry are just much different, and it’s reflecting in the workforce. There’s cultural differences too, but I think the education differences is the biggest cause.
How often do skyscrapers fall over, or bridges collapse, or your CPUs fail unexpectedly, or submarines implode. Rarely. In fact, I bet most people reading this thought of the same few examples.
Then look at software. When is the last time you encountered a bug? Have you ever heard of bug free software? Even at the elite, smartest, most educated levels of software, there are still bugs everywhere. Humans are essentially incapable of writing bug free software. And it isn’t because a bunch of uneducated dummies that didn’t get degrees are the ones writing it (as you arrogantly implied). It’s because it’s way fucking harder to do perfectly or near perfectly.
That doesn’t mean there isn’t incredibly hard physical engineering. Obviously there is insanely difficult engineering in nearly any variety. But if you ask a civil engineer to design you a perfect bridge, they probably will. Ask a software engineer with all the experience and education in the world to build you a perfect podcasting app, it simply isn’t happening.
When skyscrapers fall or bridges collapse, the negligent engineers who knowingly signed off on them go to jail. When was the last time a software developer or manager went to jail over a known bug?
Civil Engineers (the ones building bridges and skyscrapers) have a culture of institutional accountability. They are certified members of a professional organization and when they sign off on a project, they do so by affixing their personal seal to it. This is their binding endorsement of the soundness of the architectural drawings. The presence of that seal can be used as evidence in court against them (criminal or civil).
It’s also possible for engineers to be stripped of their seal by the organization for failures far less severe than a bridge collapsing, such as conflicts of interest.
There isn’t anything like that in software, even though the stakes are much lower. Far more common is a total disclaimer of warranty whatsoever.
What? That's backwards.
I guess you think that this "culture" is somehow made up and not an inherent part of the job or something?
It's straightforward: building collapses, people die => someone needs to be held accountable. Otherwise we'd be having people die all over. So there HAS to be something like this in place. It's not a choice, it's not a "culture". It's an inherent property of the universe we live in.
In that same way, this responsibility also inherently means an engineer can flag something as unsafe and he's legally protected. It can't be any other way, or nobody would want to do the job.
Also, signing off on a project is quite a bit easier when it comes down to pulling up some tables and calculating some structural loads according to well known formulas. Add some safety factor and voila - it's safe! Impossible for software.
Regardless, the simple fact is that software just matters less in almost every case, so no one gets held accountable. It lets the culture of unaccountability breed within IT / software eng, and here we are.
You want a podcast app, I will give you a formally verified podcasting app with zero bugs. I will engineer the shit out of it. Just give me a year and $500,000. Oh, you don't want to? And that right there is why we have bugs. Not because it is hard, but because nobody gives a shit. Even though companies lose way, way more than what it would cost to prevent severe bugs from happening, some things you literally cannot prevent without government regulation, as engineering itself went through after a period of nobody giving a shit and a lot of people dying as a result.
So it is harder because there is so much freedom in terms of what features a program can have and what the set of requirements can be. And that's just for getting to version 1.0. Software is expected to change much more than hardware is and if the requirements for version 1.7 can only be met by a severe change to the architecture or an ugly hack, the ugly hack will look very tempting.
Having said all that, I'm not sure I disagree all that much with you. A lot of this could be improved with more big E Engineering in the software world.
One way could be with some kind of professional engineer certification. It should be reasonably easy to get the first time by passing a test on some hard and concrete software engineering principles. But if you are ever found to break them, you lose the license and will have to go through a lot to get it back. That of course only works if companies care about people having this certification.
Which leads (as you mention) to government regulation. As someone who works with medical device software I can see that it actually works. The regulations succeed in forcing us to figure out a reasonably complete set of requirements early, but it is an ordeal. For a recent project we had working prototypes for basically all functionality and still we spent four calendar months doing nothing but requirements before we started developing the actual product.
And yet medical devices still have software bugs. There are 24 software related recalls in the FDA medical device recall database just this year so far: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRes/res...
My POV (and most people's, I think) is that software is buggier because software people are wildly unserious compared to hardware people (and other engineering disciplines like civil engineering). Which is an alright trade-off in the very large majority of cases, as software is rarely very important and is easy to update, whereas hardware and bridges are very high-stake and extremely costly to update.
> if you ask a civil engineer to design you a perfect bridge, they probably will. Ask a software engineer with all the experience and education in the world to build you a perfect podcasting app, it simply isn’t happening
The civil engineer gets to rely on extremely high-quality very-serious civil engineering work, built over millenia. The software engineer relies on shaky (ie buggy) work from past nowhere-as-serious software engineering work, built over ~70y.
The fact that the software engineer can do anything at all on such small and buggy past work shows how easy it is compared to civil engineering.
In my mind, saying "software engineering is shown to be harder by the presence of bugs" is akin to saying "LEGO building is harder, people build stuff that collapses all the time"
Yes, exactly? That's what makes it easier.
Software engineering has been a thing for, if you squint, 70 years? Comparing that to thousands of years of humans trying to pile up rocks in various ways to make houses is unserious.
Moreover, there are only so many rocks you can pile up on top of each other. Software can be infinitely complex.
How often is the civil engineer asked to add major features to his 80% finished pile of rocks? Or to move the whole pile by 50m? How long is he expected to continue feature development on it after it's been built?
> extremely high-quality very-serious civil engineering work, built over millenia
Translation: When randomly piled up rocks resulted in many dead humans we dutifully wrote down not to do that particular thing again. Repeat for a couple thousands of years and you get your very serious civil engineering work.
Fantastic analogy, and I assume you already know where I'm going with this.
The Titan submersible [0] implosion was by all accounts due to studiously ignoring best practices and test results. They shipped fast.
In contrast, James Cameron's Deepsea Challenger [1] was a slow and methodical build, and has heavily redundant backup systems for everything. For example, the ballast release system operates by demagnetizing coils that hold the ballast; that way if they have a system failure or power loss, it fails open, and they ascent. If that somehow fails, the supports for the ballast will corrode from sea water before the oxygen runs out, so in the worst case, it's sitting in the dark for a few hours before heading back up.
Or, let's look at the U.S. Navy submarine program. I was a propulsion plant operator (reactor operator + throttleman) on a Virginia-class sub. Though I can't go into specifics, "redundant" doesn't begin to describe it. FFS, the San Francisco (688-class sub) ran into an underwater mountain at flank [2] and survived. The SUBSAFE program [3] was a direct result of the loss of the Thresher [4], and to date, no SUBSAFE-certified submarine has been lost.
> Then look at software. When is the last time you encountered a bug? Have you ever heard of bug free software?
You're conflating "free of defects" with "capable of gracefully handling defects." NASA writes as close to bug-free as I think you'll find, but even theirs isn't perfect [5]. The difference is the ability for the software to work through or around those problems. Submarine / submersible design and construction is the same. Are the engineers, welders, machinists, electricians, etc. attempting to do perfect work? Of course. They also are aware that perfection is impossible, and so the design accounts for that.
0: https://en.wikipedia.org/wiki/Titan_(submersible)
1: https://en.wikipedia.org/wiki/Deepsea_Challenger
2: https://en.wikipedia.org/wiki/USS_San_Francisco_(SSN-711)#Gr...
3: https://en.wikipedia.org/wiki/SUBSAFE
4: https://en.wikipedia.org/wiki/USS_Thresher_(SSN-593)#Disaste...