4 ms·

No surprises here. Consecutive apparently identical failures should obviously be throwing up red flags, but moving fast and breaking things was always about ite

No surprises here. Consecutive apparently identical failures should obviously be throwing up red flags, but moving fast and breaking things was always about iterating. Admittedly, the line between moving fast and breaking things and throwing money into a flame trench is rather thin, but it's only a problem if they ignore their data. Data sure seems to indicate a new design is needed.

motorest 2y ago
> Admittedly, the line between moving fast and breaking things and throwing money into a flame trench is rather thin, but it's only a problem if they ignore their data. Not really. "Moving fast and breaking things" is relevant in software development circles, where a crash just means a restart and iterating means someone already on payroll has to spend some time fixing bugs. This is not the case in real engineering fields. A crash has a far more profound implication on project viability, and a greater impact on cost and project deadline. Worst case scenario, it can cost people's lives. These tradeoffs are far different in real engineering projects, to the point where in some domains an engineer can lose its ability to practice and even be thrown in jail.
- lazide 2y ago
  Uh, clearly you don’t know the history of the space race? Or any wartime project ever?
  - motorest 2y ago
    > Uh, clearly you don’t know the history of the space race? Or any wartime project ever? Comparing the tradeoffs if war with the tradeoffs of running a business is absurd. I can't put to words how silly this comparison is.
    - lazide 2y ago
      How many have died due to SpaceX’s actions again? And the space race was never a declared (or undeclared, really) war.
- rcxdude 2y ago
  If you're doing something that is a) very well understood and b) affects the safety of the public, then this is where engineering tends to be heavily regulated. It's not the definition of 'real' engineering though. And if you're trying to do something that is difficult in that it needs to be heavily optimised around thin margins, then it's very easy to spend way more time and money if you try to make it right the first time around, and you'll probably still fail compared to just building it and learning from the process, even if building it is a slow, expensive, and dangerous process.
  - motorest 2y ago
    > If you're doing something that is a) very well understood and b) affects the safety of the public, then this is where engineering tends to be heavily regulated. No, not really. Regulation is a risk management tool. You regulate activities with a recognized risk to society in general and stakeholders in particular. Consequently, you have fields where it is obligatory to have paid inspectors to verify safety and quality based on the existing standards and guidelines, and even the bulk of the design process consists in running safety verifications to prove a project is safe and reliable based on standardized procedures. This type of care for safety and reliability is not observed in software development circles. Faults and failures in general do not have a critical impact on society as a whole. The subject of testing and verifications, unlike in real engineering fields, is somehow a hotly contested debate. The primary implication of a fault or failure is downtime, whose only concerned party is the service operator. The only resources wasted addressing faults and failures are man*hour from people already on payroll. This leads to what would represent, in real engineering fields, critical process failures that could cause a project to fail and even cost lives. As it is software development, critical failures are acceptable and tolerated. A major crash at worst costs some engineer some time to sort out and recover. Seeing a rocket explode can bankrupt some companies and end peoples careers. It's mind numbingly stupid to extend software development principles and practices to real engineering fields. The resources spent are not the same, nor are the implications of failure. Stakes are much higher, and naturally so is scrutiny and consequences.
    - birdiesanders 2y ago

motorest 2y ago

> Admittedly, the line between moving fast and breaking things and throwing money into a flame trench is rather thin, but it's only a problem if they ignore their data. Not really. "Moving fast and breaking things" is relevant in software development circles, where a crash just means a restart and iterating means someone already on payroll has to spend some time fixing bugs. This is not the case in real engineering fields. A crash has a far more profound implication on project viability, and a greater impact on cost and project deadline. Worst case scenario, it can cost people's lives. These tradeoffs are far different in real engineering projects, to the point where in some domains an engineer can lose its ability to practice and even be thrown in jail.

lazide 2y ago
Uh, clearly you don’t know the history of the space race? Or any wartime project ever?
- motorest 2y ago
  > Uh, clearly you don’t know the history of the space race? Or any wartime project ever? Comparing the tradeoffs if war with the tradeoffs of running a business is absurd. I can't put to words how silly this comparison is.
  - lazide 2y ago
    How many have died due to SpaceX’s actions again? And the space race was never a declared (or undeclared, really) war.
rcxdude 2y ago
If you're doing something that is a) very well understood and b) affects the safety of the public, then this is where engineering tends to be heavily regulated. It's not the definition of 'real' engineering though. And if you're trying to do something that is difficult in that it needs to be heavily optimised around thin margins, then it's very easy to spend way more time and money if you try to make it right the first time around, and you'll probably still fail compared to just building it and learning from the process, even if building it is a slow, expensive, and dangerous process.
- motorest 2y ago
  > If you're doing something that is a) very well understood and b) affects the safety of the public, then this is where engineering tends to be heavily regulated. No, not really. Regulation is a risk management tool. You regulate activities with a recognized risk to society in general and stakeholders in particular. Consequently, you have fields where it is obligatory to have paid inspectors to verify safety and quality based on the existing standards and guidelines, and even the bulk of the design process consists in running safety verifications to prove a project is safe and reliable based on standardized procedures. This type of care for safety and reliability is not observed in software development circles. Faults and failures in general do not have a critical impact on society as a whole. The subject of testing and verifications, unlike in real engineering fields, is somehow a hotly contested debate. The primary implication of a fault or failure is downtime, whose only concerned party is the service operator. The only resources wasted addressing faults and failures are man*hour from people already on payroll. This leads to what would represent, in real engineering fields, critical process failures that could cause a project to fail and even cost lives. As it is software development, critical failures are acceptable and tolerated. A major crash at worst costs some engineer some time to sort out and recover. Seeing a rocket explode can bankrupt some companies and end peoples careers. It's mind numbingly stupid to extend software development principles and practices to real engineering fields. The resources spent are not the same, nor are the implications of failure. Stakes are much higher, and naturally so is scrutiny and consequences.
  - birdiesanders 2y ago