Our whole "I can't do work today, I have to apply these security fixes 83 levels deep" also sounds a lot like: https://practical.engineering/blog/2022/8/2/you-spend-more-o...
All in all, yeah, I don't understand the inferiority complex. Engineering always looks amazing to people that aren't in the thick of it, but we hide a lot of the flaws, and fix the other ones through iteration.
Just because you can doesn't mean that you should. Of course, with software that is truly noncritical, handling failure modes can be optimized away in favor of shipping-the-new-version sooner. That doesn't mean that it is a good thing.
The fact that this is so prevalent in the software industry is why the general public sees most software and indeed technology ("software is eating the world...") as a plague — time and time again, NO effort is made to ensure that things fail-safe, or even that they fail-gracefully.
So the user experience is that tech is good enough that we sort of have to use it (it's better than paper), but so bad that it is endlessly frustrating, whether it's endless glitches in client or web apps, data that gets mysteriously lost or corrupted, Bluetooth still screwing up connections, UI 'designs' that hide key functions behind a 'clean' interface that is nonetheless inscrutable for the occasional user... the entire industry has created a world no one wants to live in, one little decision at a time.
(And that doesn't even begin to account for software that kills people by bad decisions or oversights.)
The fact that an article such as this one is even necessary — that it is NOT simply assumed that an absolutely key part of the design process of every piece of software is to consider all failure modes and how to handle them in a way that is safe and graceful — casts a real shadow over the software industry, and shows why it is still separate from real engineering (despite software often being more complex).
Ariane flight V88 haunts your nightmares.
Hyatt Regency walkways too.
Apollo 1.
Plenty of examples, actually. All engineering fields have their share of catastrophic failures. For better or worse, that’s how we learn.
For additional context to the mental imagery, I thought it would be appropriate to link FOOF: https://en.wikipedia.org/wiki/Dioxygen_difluoride
Software is way more of a craft than engineering.
Fits software eng. just fine
Not even close. But we sure love to claim the principles were scientific. A programmer becomes good at his craft with time and experience. Not by studying in school and learning the principles there. A classic difference between a craft and engineering.
How many large construction projects fail due to incorrect engineering compared to large software projects?
> or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions;
Almost never.
Isn’t this the key point? That *most* “software engineering” is not engineering. I can build a bridge and not be an engineer; similarly I can build software and not be an engineer. The properties of the bridge/software is what makes the difference isn’t it?
> How many large construction projects fail due to incorrect engineering compared to large software projects?
Yes, poor engineering is rampant. But I will argue that malleability also plays a large role in the delta. In traditional engineering you build a car (and you are “done”). In software you build a car and get asked to make it an aeroplane without going back to the drawing board.
You can also pay to have software built. The specs will not be even remotely as precisely defined and the building of the product will not even remotely follow a standardized set of steps. It will come down to a team and individual programmers implementing features as they see fit.
Software that was running space shuttles was famously engineered. The costs in terms of time and money was astronomical.
> Yes, poor engineering is rampant. But I will argue that malleability also plays a large role in the delta. In traditional engineering you build a car (and you are “done”). In software you build a car and get asked to make it an aeroplane without going back to the drawing board.
Which is why it is not engineering. It is a craft much closer to writing a novel than it is to engineering as it looks in other disciplines.
And of course there is often no regulations that would require and guarantee the application of such a standard, and no standardized QA by customers.
My suspicion is that, if you start trying to get specific, you can actually find standardized steps at the same level of abstraction in programming. But since construction superficially looks like "stamp out multiple copies of the same thing" whereas programming is superficially "everything is its own special sauce," people try comparing them at different levels of abstraction.
I think using that as a basis for this conclusion is wrong. Software changes a lot because it’s possible and “CHEAP” to do so compared to engineering in the meat world. This is a business pressure/decision. If companies can easily and cheaply modify bridges arbitrarily, I believe they will; and this wouldn’t have any bearing on whether it’s engineering.
> Software that was running space shuttles was famously engineered.
This is exactly my point: Most swans are white, doesn’t mean all swans are white.
Software engineer applies computer science theory in real world where he she is constrained by real world factors
If computer science is not enough "scientific" the idk
>A programmer becomes good at his craft with time and experience. Not by studying in school and learning the principles there. A classic difference between a craft and engineering.
All of them are required to become good software engineer.
Solid theory, proficiency in hands and exp.
A good 90% of people with that title are flying blind as if they lived the wild west
A good 90% of the rest almost never do that (regardless if because they don't know how, or the company won't let them)
The rest will make the news of they fail, so they put an amount of effort and time which reflect that
We skipped the "mechanic" equivalent in the software industry and call anyone that can pass fizzbuzz, and who does work like fizzbuzz, an engineer
Software engineers do a lot of tinkering, and almost no engineering. Which is fine by me, actual engineering is a PITA and tinkering is where the fun is at
If I have engineer in job_title and engineering degree in informatics, then I m an engineer by your "standards/definitions"?
Yes, although those fellas mostly don't pretend their jobs involve designing and validating mechanisms with any scientific and industry regulation / standard rigour
Since you didn't specify the job_title involves any actual engineering, I'm gonna assume it doesn't... just like most job_titles
I too have a piece of paper saying I'm a Computer Engineer BSc (didn't apply for any of the electronics/CE licenses back home because wages were shit and the license wouldn't have been worth anything overseas)
Half of SEs consider the idea of written requirements needless bullshit that just drag you down. Validating your designs with any sort of rigour just isn't there for the vast, vast majority of jobs. As such, calling it "engineering" is a joke
If the activities of your regular Software Engineer can be said to be engineering, so should be changing a tyre. There isn't nearly enough rigour in the process to warrant calling it "engineering"
I would not be comfortable shipping code that has undefined behavior, outcome, or consequence. It takes a small amount of effort to build functions/methods with defined but encompassing outputs.
Although complexity probably scales parabolically in certain use cases.
Engineering is all about turning science into products. Anyone with a chemical lab and enough post-grad grunt can make a compound. That's just the start. Getting it to customers, at scale, with a saleable price and not selling poison, contamination, or thin air and not turning your plant into a crater or superfund site is the task. It just happens to involve a bit of chemistry along the way.
You can't just complain from the smoking ruins of your startup "but the happy path we tweeted about when we did it in a flask worked fine, how could we know it would be hard to make 50 tons of FOOF a day?"
It's not always glamorous, it's not always fun, it's not even always innovative, it's almost certainly never easy, but it is what you're actually selling, and it's why you're the one selling it and not someone else.
Now, can you cut corners and make it work, say, 99% of the time and that's good enough to ship it and sit back[1]? Sure you can. But if someone comes along at 99.9% and the same price, or even a higher price and your customers will pay for that extra 9, you're in trouble.
[1]: or ship 99% code thinking it's 100% because you didn't check