3 ms·

Software engineering is not like physical engineering. I've done both and they necessarily operate from different assumptions about the world. In software, a s

Software engineering is not like physical engineering. I've done both and they necessarily operate from different assumptions about the world. In software, a single bit-flip or typo can lead to catastrophic failure, it is sensitive to defects in a way physical systems are not. The behavior of software is dependent on the behavior of the hardware it runs on; unlike physical engineering, the hardware for software is not engineered to the specifications of the design, it has to run on unknown hardware with unknown constraints and work correctly the first time. Physical systems are inherently resilient in the presence of many small defects, a property that physical engineering relies on greatly. Software is much less tolerant of defects, and there is a limited ability to "over-engineer" software to add safety margin, which is done all the time in physical engineering but is qualitatively more expensive in software engineering. Being broken is often a binary state in software. I've written software for high-assurance environments. Every detail of the implementation must be perfect to a degree that would make engineers with even the most perfectionist tendencies blush. Physical engineering requires nothing like this degree of perfectionism. In my experience, the vast majority of engineers are not cognitively equipped to engineer to that standard, and in physical engineering they don't have to.

hn367621 2y ago
> physical engineering they don't have to Totally agree with what you wrote but in any well run engineering organization one has to consider the cost/benefit of extra testing and engineering. If you're making a USB powered LED desk lamp, you get into diminishing returns fairly quickly. If you're making basically anything on JWST, less so.
- kevin_thibedeau 2y ago
  There is no excuse for making defective products, no matter how low the profit margins are. The key why properly engineered anything works is that safety margins are baked into the design. Every real engineering field uses repeatable processes with known likelihood of success. Software "engineering" doesn't do that.
  - hn367621 2y ago
    Defective means a product doesn’t deliver on its specifications. For example if my LED desk lamp doesn’t promise to last any time at all, it’s not defective if it fails inside a month. If you want one that lasts longer, you pay more and can have that. Same for software. But most software basically promises nothing…
  - jandrewrogers 2y ago
    The concept of "safety margins" in physical engineering are largely nonsensical in a software context. In physical systems, correctness is a bulk statistical property of the design, an aggregate of probability distributions, which makes safety simple. If you are uncertain, add a bit more steel just in case, it is very cheap insurance. Physical systems are defect tolerant, they aren't even close to defect-free. In software systems, correctness is binary, so they actually have to be defect-free. Defects don't manifest gradually and gracefully like they often do in physical systems.
  - datadrivenangel 2y ago
    Much better to think about low-quality products instead of defective. Junk can still be useful, and just good enough is definitionally good enough (most of the time). Also, most real engineering fields are full of projects that are done in non-repeatable ways and go horribly over budget. You're correct that for implementation you can get repeatable processes, but for process improvement you don't have anywhere near the level of repeatability.
bdangubic 2y ago
fantastic post. what I will “disagree” on Every detail of the implementation must be perfect to a degree that would make engineers with even the most perfectionist tendencies blush the amount of software that fits this description is likely comparable to amount of physical engineering that requires the same perfectionism…
UltraSane 2y ago
I once found a company selling a password server like Thycotic Secret Server that must have been written by a madman. It used secret sharing to split the passwords into 3 of 5 shards and stored them on 5 different servers. He wrote the server in two different languages and it was meant to run on both windows and Linux and BSD to prevent common bugs. I don't remember the name and can't find it anymore. AWS is using a lot of Formal Verification and Automated theorem proving on their core systems like S3 and TLS to increase reliability.
lisper 2y ago
> In software, a single bit-flip or typo can lead to catastrophic failure That can happen in physical engineering too, if it's not done right. Likewise, if a single bit flip can lead to catastrophic failure, that's an indication that the system was poorly engineered. The problem with software is not so much that it is fundamentally different in terms of its failure response (though there certainly are differences -- the laws of physics provide important constraints on hardware that are absent in software) but rather that it is so easy to copy, which tends to entrench early design decisions and make them difficult to go back and change because the cost is too high (e.g. syntactically-significant tabs in 'make'). But even that can and does happen in physical design as well. The Millennium Tower in San Francisco is the best example I can think of. The World Trade Center is another example of a design that failed because the failure mode that destroyed it was not part of the original design requirements. When the WTC was designed, no one imagined that someone would fly a jet into them some day. Today's adversarial environment was similarly hard to imagine before the Internet. It absolutely is possible to engineer software for robustness, reliability, and trustworthiness. The limiting factor is economics, not engineering.
hulitu 2y ago
> In software, a single bit-flip or typo can lead to catastrophic failure That's why you have tests for this. The main problem that i see with software, is that the testing and bug finding part are left to the user. And, when testing is done, it is done as easy as possible. For example a function must return 5 when it has 8 as an input. They only test for 5 as an input value and 2 or -1 are left to the user to test them.

hn367621 2y ago

> physical engineering they don't have to Totally agree with what you wrote but in any well run engineering organization one has to consider the cost/benefit of extra testing and engineering. If you're making a USB powered LED desk lamp, you get into diminishing returns fairly quickly. If you're making basically anything on JWST, less so.

kevin_thibedeau 2y ago
There is no excuse for making defective products, no matter how low the profit margins are. The key why properly engineered anything works is that safety margins are baked into the design. Every real engineering field uses repeatable processes with known likelihood of success. Software "engineering" doesn't do that.
- hn367621 2y ago
  Defective means a product doesn’t deliver on its specifications. For example if my LED desk lamp doesn’t promise to last any time at all, it’s not defective if it fails inside a month. If you want one that lasts longer, you pay more and can have that. Same for software. But most software basically promises nothing…
- jandrewrogers 2y ago
  The concept of "safety margins" in physical engineering are largely nonsensical in a software context. In physical systems, correctness is a bulk statistical property of the design, an aggregate of probability distributions, which makes safety simple. If you are uncertain, add a bit more steel just in case, it is very cheap insurance. Physical systems are defect tolerant, they aren't even close to defect-free. In software systems, correctness is binary, so they actually have to be defect-free. Defects don't manifest gradually and gracefully like they often do in physical systems.
- datadrivenangel 2y ago
  Much better to think about low-quality products instead of defective. Junk can still be useful, and just good enough is definitionally good enough (most of the time). Also, most real engineering fields are full of projects that are done in non-repeatable ways and go horribly over budget. You're correct that for implementation you can get repeatable processes, but for process improvement you don't have anywhere near the level of repeatability.

bdangubic 2y ago

fantastic post. what I will “disagree” on Every detail of the implementation must be perfect to a degree that would make engineers with even the most perfectionist tendencies blush the amount of software that fits this description is likely comparable to amount of physical engineering that requires the same perfectionism…

UltraSane 2y ago

I once found a company selling a password server like Thycotic Secret Server that must have been written by a madman. It used secret sharing to split the passwords into 3 of 5 shards and stored them on 5 different servers. He wrote the server in two different languages and it was meant to run on both windows and Linux and BSD to prevent common bugs. I don't remember the name and can't find it anymore. AWS is using a lot of Formal Verification and Automated theorem proving on their core systems like S3 and TLS to increase reliability.

lisper 2y ago

> In software, a single bit-flip or typo can lead to catastrophic failure That can happen in physical engineering too, if it's not done right. Likewise, if a single bit flip can lead to catastrophic failure, that's an indication that the system was poorly engineered. The problem with software is not so much that it is fundamentally different in terms of its failure response (though there certainly are differences -- the laws of physics provide important constraints on hardware that are absent in software) but rather that it is so easy to copy, which tends to entrench early design decisions and make them difficult to go back and change because the cost is too high (e.g. syntactically-significant tabs in 'make'). But even that can and does happen in physical design as well. The Millennium Tower in San Francisco is the best example I can think of. The World Trade Center is another example of a design that failed because the failure mode that destroyed it was not part of the original design requirements. When the WTC was designed, no one imagined that someone would fly a jet into them some day. Today's adversarial environment was similarly hard to imagine before the Internet. It absolutely is possible to engineer software for robustness, reliability, and trustworthiness. The limiting factor is economics, not engineering.

hulitu 2y ago

> In software, a single bit-flip or typo can lead to catastrophic failure That's why you have tests for this. The main problem that i see with software, is that the testing and bug finding part are left to the user. And, when testing is done, it is done as easy as possible. For example a function must return 5 when it has 8 as an input. They only test for 5 as an input value and 2 or -1 are left to the user to test them.