3 ms·

To commenters who compare work of programmer with the work of civil engineer: There is an explanation to this discrepancy. Risk = probability of fault * cost o

by h91wka 6y ago

To commenters who compare work of programmer with the work of civil engineer: There is an explanation to this discrepancy. Risk = probability of fault * cost of fault. Programmers usually work with the data. Data has a pretty very unique property that it is easily and cheaply copied and restored. It also means data can be replicated more easily, which allows to build systems with large amount of redundancy. Therefore, price of a software bug is usually orders of magnitude less than the price of breaking something in the physical world. This allows to drive up probability of fault parameter and allows for much faster evolution and less regulation.

mdtusz 6y ago
I think a part that needs to be considered in the comparison is also the concept of safety factors. Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles. Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field. Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.
cryptonector 6y ago
Replication costs have nothing to do with anything here. The damage caused by a software bug can range from nil (even negative, since a bug might have desirable effects) to incalculable. Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispenser. Or... You can compare the work of a programmer to the work of a civil engineer, but it's true that it's difficult because most bugs cost little, much software is not positioned to cause much damage if buggy, software bugs are so prevalent, and it's so difficult to write bug-free code. But the cost of replication of software has nothing to do with any of this.
- h91wka 6y ago
  > Replication costs have nothing to do with anything here. Replication is the cornerstone of fault-tolerance. When logic is written in high-level languages with some minimal good practices, most SW bugs result in crashes rather than data corruption, hence data replication plays important role in protection against bugs as well as HW problems. > Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispense I specifically mentioned: "Programmers _usually_ work with the data. <...>" In the examples you listed above software manipulates physical world rather than pure data. I thought it was too obvious to explain.

by h91wka 6y ago

mdtusz 6y ago

I think a part that needs to be considered in the comparison is also the concept of safety factors. Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles. Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field. Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.

cryptonector 6y ago

Replication costs have nothing to do with anything here. The damage caused by a software bug can range from nil (even negative, since a bug might have desirable effects) to incalculable. Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispenser. Or... You can compare the work of a programmer to the work of a civil engineer, but it's true that it's difficult because most bugs cost little, much software is not positioned to cause much damage if buggy, software bugs are so prevalent, and it's so difficult to write bug-free code. But the cost of replication of software has nothing to do with any of this.

h91wka 6y ago
> Replication costs have nothing to do with anything here. Replication is the cornerstone of fault-tolerance. When logic is written in high-level languages with some minimal good practices, most SW bugs result in crashes rather than data corruption, hence data replication plays important role in protection against bugs as well as HW problems. > Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispense I specifically mentioned: "Programmers _usually_ work with the data. <...>" In the examples you listed above software manipulates physical world rather than pure data. I thought it was too obvious to explain.