I don’t. I think we’ll zoom right past that benchmark. In a couple years your grandma will be able to build real, ambitious software with AI better than you can today. Shortly after that AI won’t even need Grandma.
> you'll be able to be similarly dismissive and condescending to them, too
And? Who are these people that need all this sympathy from internet strangers? Grow the fuck up and go solve your own damn problems. I can’t stand these “I need internet strangers to tell me that my life is, in fact, hard” people.
Well, given that you’re not a Tesla shareholder, you likely give poor financial advice anyway. How long have people been trying to short Tesla? A decade at least?
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.
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"
> The civil engineer gets to rely on extremely high-quality very-serious civil engineering work, built over millenia.
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.
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?
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.
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.
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.
> There isn’t anything like that in software, even though the stakes are much lower.
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.
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.
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.
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.
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.
Yep, I really wish I could revert to previous-Siri on my iPhone 15 Pro. Old Siri was reasonably predictable and faster. New Siri is slower, more ambitious, and fails more often.
you can. i just did it on my 17 pro and my watch. i get instant timers again. it's unreal we lost this technology.
go to settings > siri > and turn off siri entirely. it doesn't break anything. then turn it back on, and they give you the option for siri AI or old dumb siri.
The text-only purists on HN are getting very tiresome. It’s seriously in every fucking post that links to a site with JavaScript enabled. We get it. You’re elite. Now stop talking about it.
> What actually happened is cooler than what could happen
It’s hard to think of a fictional story that beats actually rowing across the world.
reply