| Nah. That’s not it. Software is just legitimately harder than most physical engineering (notice I didn’t say all). 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. |
| |
| ▲ | williamdclt 5 hours ago | parent | next [-] | | You're literally the first person I've ever seen suggesting this, I actually thought you were being sarcastic! 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" | |
| ▲ | tarsierscripter 12 hours ago | parent | prev | next [-] | | How often do skyscrapers fall over, or bridges collapse 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? | | |
| ▲ | vlovich123 10 hours ago | parent [-] | | People going to jail for such failures are actually quite rarer than you imply. And generally software bugs rarely cause similar damage either in lives or money lost. | | |
| ▲ | NamTaf 10 hours ago | parent | next [-] | | A better comparison to software bugs is, say, early fatigue cracking in a structure that requires retrofits to fix. 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. | |
| ▲ | tarsierscripter 10 hours ago | parent | prev [-] | | None of that invalidates my point. 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. |
|
| |
| ▲ | matwood 2 hours ago | parent | prev | next [-] | | I don't think it's whether one is harder than the other, it's about constraints or in software, lack of. Hardware is constrained by the physical world while software has much fewer constraints leading to a huge number of permutations. | |
| ▲ | applfanboysbgon 8 hours ago | parent | prev | next [-] | | lol no. This is just a sort of learned helplessness that is endemic in the industry. A way to protect your ego: nobody could have avoided shipping that critical bug to production, so it's not your incompetence that led you to do it! 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. | | |
| ▲ | sehansen an hour ago | parent [-] | | The reason is people don't want to specify the full set of requirements to that podcast app ahead of time. You can spend your year and $500,000 and then the users will play around with it for ten minutes and then tell you it needs to do this and that as well. And one of those features requires you to go back and make fundamental changes to your architecture making you redo a lot of your subsequent work, including a lot of the formal verification. 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... |
| |
| ▲ | sgarland 20 minutes ago | parent | prev [-] | | > submarines implode 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... 5: https://space.stackexchange.com/a/37694 |
|
