5 ms·

See, treating this as an add-on is why software has a reputation as "not real engineering". Engineering is all about turning science into products. Anyone with

See, treating this as an add-on is why software has a reputation as "not real engineering". 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

runnerup 4y ago
> Anyone with a chemical lab...not turning your plant into a crater or superfund site...how could we know it would be hard to make 50 tons of FOOF a day? For additional context to the mental imagery, I thought it would be appropriate to link FOOF: https://en.wikipedia.org/wiki/Dioxygen_difluoride https://en.wikipedia.org/wiki/Dioxygen_difluoride
- wantoncl 4y ago
  More imagery: https://www.science.org/content/blog-post/things-i-won-t-work-dioxygen-difluoride https://www.science.org/content/blog-post/things-i-won-t-wor...
  - cratermoon 4y ago
    "Satan's Kimchi" is the name of my new KPop/Black Metal crossover band
shanebellone 4y ago
I found this example particularly engaging. 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.
stdbrouw 4y ago
I don't understand this kind of inferiority complex. In software engineering we can often afford to wing it in a way that other kinds of engineering can't because they are strongly locked into what they've built already and because human life is at play. You can't really redo the foundation of a pre-existing building without a truly heroic amount of work, and you can't reboot a person if their pacemaker fails. When presented with those same conditions, software engineering tends to be just as rigorous as any other kind of engineering, e.g. NASA, medical software, and so on. I'd argue that is what defines engineering: you optimize for the things that matter and don't get carried away trying to pursue the most elegant or robust system at all costs – that would be science or art. Your competitor who is not cutting corners won't beat you with their 99.9% product, they will just never get off the ground. Meanwhile, you're at 99.5% and climbing.
- cratermoon 4y ago
  > In software engineering we can often afford to wing it in a way that other kinds of engineering can't Ariane flight V88 haunts your nightmares.
  - Swizec 4y ago
    Galloping Gertie haunts civil engineer’s 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.
    - MrJohz 4y ago
      Different problems also have different scales. The road that they've repaved outside my house has had far less scrutiny than the new bridge they've built down the road. And NASA have very different coding guidelines to Shopify.
- toss1 4y ago
  >> In software engineering we can often afford to wing it in a way that other kinds of engineering can't ... 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).
rapsey 4y ago
> See, treating this as an add-on is why software has a reputation as "not real engineering". Software is way more of a craft than engineering.
- hardware2win 4y ago
  >The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property Fits software eng. just fine
  - rapsey 4y ago
    > The creative application of scientific principles to design or develop 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.
    - elvis10ten 4y ago
      > 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.
m_mueller 4y ago
> when we did it in a flask worked fine kinda funny how Flask has a toy server that's probably behind a lot of startup MVPs....
l0b0 4y ago
Excellent analogy, and one of the reasons just putting a bunch of smart people together isn't good business model. A large fraction of them might be capable of building algorithmically outstanding software, but that skill set is completely orthogonal to building a product, testing it, integrating it with third party software and/or hardware, maintaining it, and ultimately migrating away from it to the next generation of software.

runnerup 4y ago

> Anyone with a chemical lab...not turning your plant into a crater or superfund site...how could we know it would be hard to make 50 tons of FOOF a day? For additional context to the mental imagery, I thought it would be appropriate to link FOOF: https://en.wikipedia.org/wiki/Dioxygen_difluoride https://en.wikipedia.org/wiki/Dioxygen_difluoride

wantoncl 4y ago
More imagery: https://www.science.org/content/blog-post/things-i-won-t-work-dioxygen-difluoride https://www.science.org/content/blog-post/things-i-won-t-wor...
- cratermoon 4y ago
  "Satan's Kimchi" is the name of my new KPop/Black Metal crossover band

shanebellone 4y ago

I found this example particularly engaging. 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.

stdbrouw 4y ago

I don't understand this kind of inferiority complex. In software engineering we can often afford to wing it in a way that other kinds of engineering can't because they are strongly locked into what they've built already and because human life is at play. You can't really redo the foundation of a pre-existing building without a truly heroic amount of work, and you can't reboot a person if their pacemaker fails. When presented with those same conditions, software engineering tends to be just as rigorous as any other kind of engineering, e.g. NASA, medical software, and so on. I'd argue that is what defines engineering: you optimize for the things that matter and don't get carried away trying to pursue the most elegant or robust system at all costs – that would be science or art. Your competitor who is not cutting corners won't beat you with their 99.9% product, they will just never get off the ground. Meanwhile, you're at 99.5% and climbing.

cratermoon 4y ago
> In software engineering we can often afford to wing it in a way that other kinds of engineering can't Ariane flight V88 haunts your nightmares.
- Swizec 4y ago
  Galloping Gertie haunts civil engineer’s 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.
  - MrJohz 4y ago
    Different problems also have different scales. The road that they've repaved outside my house has had far less scrutiny than the new bridge they've built down the road. And NASA have very different coding guidelines to Shopify.
toss1 4y ago
>> In software engineering we can often afford to wing it in a way that other kinds of engineering can't ... 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).

rapsey 4y ago

> See, treating this as an add-on is why software has a reputation as "not real engineering". Software is way more of a craft than engineering.

hardware2win 4y ago
>The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property Fits software eng. just fine
- rapsey 4y ago
  > The creative application of scientific principles to design or develop 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.
  - elvis10ten 4y ago
    > 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.

m_mueller 4y ago

> when we did it in a flask worked fine kinda funny how Flask has a toy server that's probably behind a lot of startup MVPs....

l0b0 4y ago

Excellent analogy, and one of the reasons just putting a bunch of smart people together isn't good business model. A large fraction of them might be capable of building algorithmically outstanding software, but that skill set is completely orthogonal to building a product, testing it, integrating it with third party software and/or hardware, maintaining it, and ultimately migrating away from it to the next generation of software.