6 ms·

> I'm sure the on-board systems were designed and developed by people who know what they are doing. I have been working in safety-related domains, where each f

by wott 10y ago

> I'm sure the on-board systems were designed and developed by people who know what they are doing. I have been working in safety-related domains, where each failure could involve the death of several hundred people. It wasn't pretty: everything was sub-contracted to death, and there were a minority of people who really knew what they were doing, a majority who was so-so and didn't give a fuck, and still a fair part who was notoriously incompetent. So, the minority of competent and concerned people cannot always make up for the others, and when themselves fail, there is almost no one to make up for them. Oh, and I was working in a company that was supposed to produce better quality than others. And it did :-( So, for something like ESA where life is not even concerned, I can't imagine it is any better if stuff is outsourced, and since nowadays almost everything everywhere is outsourced, I assume ESA does it too. > Sometimes I wonder whether majority of software errors are caused only by multiple layers of people having incorrect / unchallenged / unjustified (and mostly implicit) assumptions about something. Yes and no. This causes a category of mistakes but on the other hand, it prevents another category. When someone knows the full system, he makes a whole lot of assumptions: it doesn't matter if this function cannot handle this or that case because it will never be called this way, it cannot happen, so I won't handle those cases and I won't even check them. And then, later, something changes in an upper function or system, the assumption is not valid any more, and boom. When you have no idea what the system is, you just stick to the function definition and have it handle all the weird cases. You don't make assumptions. You can still make mistakes, though, some of them caused by the lack of global understanding of the system because the specification writer had those assumptions in mind and did not write them down in the specification of this function because they were obvious to him or they were already written in another part of the specification.

acqq 10y ago
> And then, later, something changes in an upper function or system, the assumption is not valid any more, and boom. That's exactly how Ariane 5 crashed in 1996: https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_failure https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_fa... "Specifically, the Ariane 5's greater horizontal acceleration caused the computers in both the back-up and primary platforms to crash and emit diagnostic data misinterpreted by the autopilot as spurious position and velocity data. Pre-flight tests had never been performed on the inertial platform under simulated Ariane 5 flight conditions so the error was not discovered before launch. During the investigation, a simulated Ariane 5 flight was conducted on another inertial platform. It failed in exactly the same way as the actual flight units."
- simonh 10y ago
  >Pre-flight tests had never been performed on the inertial platform under simulated Ariane 5 flight conditions I had to read that several times, just to make sure it said what I thought it said.
- fghgfdfg 10y ago
  I think it's also important to note that the inertial platform was developed for the Ariane 4 where it worked correctly. The software was actually developed correctly, and functioned as intended. At least for it's intended use. Then it was tossed at a new use-case without any accounting for any differences in the new situation.
  - acqq 10y ago
    > The software was actually developed correctly Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5) or the duration of the spinning movement (this case now) doesn't match their initial test cases. Still, the development, especially in this kind of projects, is always a balancing act to organize covering most of the cases that can go wrong. Murphy's law works against the whole organization. Given the amount of real problems, I'm still amazed that the Apollo 11 succeeded. Or even that there weren't any really destructive "accidents" involving rockets with the nuclear warheads. Think about it, these are prone to the same problems any other computer-related projects are: the amount of the damage is effectively infinitely larger than the effort needed to start it. https://www.theguardian.com/world/2016/jan/07/nuclear-weapons-risk-greater-than-in-cold-war-says-ex-pentagon-chief https://www.theguardian.com/world/2016/jan/07/nuclear-weapon... “These weapons are literally waiting for a short stream of computer signals to fire. They don’t care where these signals come from.” “Their rocket engines are going ignite and their silo lids are going to blow off and they are going to lift off as soon as they have the equivalent of you or I putting in a couple of numbers and hitting enter three times.” http://thebulletin.org/ http://thebulletin.org/ "It is 3 minutes to midnight" Also: "How Risky is Nuclear Optimism?" http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf And if you still think "but it works, the proof is that it hasn't exploded up to now", just consider this graph from Nassim Taleb: http://static3.businessinsider.com/image/5655f69c8430765e008b57c8-1200-900/taleb-turkey.png http://static3.businessinsider.com/image/5655f69c8430765e008...
woliveirajr 10y ago
> When you have no idea what the system is, you just stick to the function definition and have it handle all the weird cases. You don't make assumptions. You can still make mistakes, though, some of them caused by the lack of global understanding of the system because the specification writer had those assumptions in mind and did not write them down in the specification of this function because they were obvious to him or they were already written in another part of the specification. This, alone, deserves an article. It's a fundamental knowledge in any software development made by different teams, or even a discussion about the pros vs cons of having a monolithic team versus distributed teams. If you expect that small teams, doing parts of a project, take care of all possible interactions of their piece of program with all other components, you'll fail. They just have a subset of the knowledge, and how all those information was passed so that they could act is relevant. And in general nobody writes down every single detail that could make a difference. In those scenarios, analysts who are able to write requisites until the point that some can be considered non-sense or obvious, should be paid in gold.
- pjmlp 10y ago
  Which is why actual C and C++ code written at these companies, in these type of projects is so "fun" to debug. Yes, everyone can be a super coder on his little bubble and use all the latest techniques to write high quality code, the problems arise when his/her bubble needs to interact with an ocean of unseen bubbles, many of which tainted ones.
  - ethbro 10y ago
    The longer I've coded in practice, the more suspicious I've gotten about "you don't need any domain knowledge, here are perfect specifications" approaches. The fingers on the keyboard should always have some grasp of the bigger picture, or bad things are likely to happen.
    - pjmlp 10y ago
      Fully agree, I never understood the stereotype of coder closed in a cubicle breaking LOC records, coding without any other knowledge than programing language and libraries. I always have spent a big part of my time interacting with those that would eventually use the programs/libraries. Without domain knowledge and communication skills, there is a high probability of misunderstandings.

by wott 10y ago

acqq 10y ago

> And then, later, something changes in an upper function or system, the assumption is not valid any more, and boom. That's exactly how Ariane 5 crashed in 1996: https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_failure https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_fa... "Specifically, the Ariane 5's greater horizontal acceleration caused the computers in both the back-up and primary platforms to crash and emit diagnostic data misinterpreted by the autopilot as spurious position and velocity data. Pre-flight tests had never been performed on the inertial platform under simulated Ariane 5 flight conditions so the error was not discovered before launch. During the investigation, a simulated Ariane 5 flight was conducted on another inertial platform. It failed in exactly the same way as the actual flight units."

simonh 10y ago
>Pre-flight tests had never been performed on the inertial platform under simulated Ariane 5 flight conditions I had to read that several times, just to make sure it said what I thought it said.
fghgfdfg 10y ago
I think it's also important to note that the inertial platform was developed for the Ariane 4 where it worked correctly. The software was actually developed correctly, and functioned as intended. At least for it's intended use. Then it was tossed at a new use-case without any accounting for any differences in the new situation.
- acqq 10y ago
  > The software was actually developed correctly Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5) or the duration of the spinning movement (this case now) doesn't match their initial test cases. Still, the development, especially in this kind of projects, is always a balancing act to organize covering most of the cases that can go wrong. Murphy's law works against the whole organization. Given the amount of real problems, I'm still amazed that the Apollo 11 succeeded. Or even that there weren't any really destructive "accidents" involving rockets with the nuclear warheads. Think about it, these are prone to the same problems any other computer-related projects are: the amount of the damage is effectively infinitely larger than the effort needed to start it. https://www.theguardian.com/world/2016/jan/07/nuclear-weapons-risk-greater-than-in-cold-war-says-ex-pentagon-chief https://www.theguardian.com/world/2016/jan/07/nuclear-weapon... “These weapons are literally waiting for a short stream of computer signals to fire. They don’t care where these signals come from.” “Their rocket engines are going ignite and their silo lids are going to blow off and they are going to lift off as soon as they have the equivalent of you or I putting in a couple of numbers and hitting enter three times.” http://thebulletin.org/ http://thebulletin.org/ "It is 3 minutes to midnight" Also: "How Risky is Nuclear Optimism?" http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf http://www-ee.stanford.edu/%7Ehellman/publications/75.pdf And if you still think "but it works, the proof is that it hasn't exploded up to now", just consider this graph from Nassim Taleb: http://static3.businessinsider.com/image/5655f69c8430765e008b57c8-1200-900/taleb-turkey.png http://static3.businessinsider.com/image/5655f69c8430765e008...

woliveirajr 10y ago

> When you have no idea what the system is, you just stick to the function definition and have it handle all the weird cases. You don't make assumptions. You can still make mistakes, though, some of them caused by the lack of global understanding of the system because the specification writer had those assumptions in mind and did not write them down in the specification of this function because they were obvious to him or they were already written in another part of the specification. This, alone, deserves an article. It's a fundamental knowledge in any software development made by different teams, or even a discussion about the pros vs cons of having a monolithic team versus distributed teams. If you expect that small teams, doing parts of a project, take care of all possible interactions of their piece of program with all other components, you'll fail. They just have a subset of the knowledge, and how all those information was passed so that they could act is relevant. And in general nobody writes down every single detail that could make a difference. In those scenarios, analysts who are able to write requisites until the point that some can be considered non-sense or obvious, should be paid in gold.

pjmlp 10y ago
Which is why actual C and C++ code written at these companies, in these type of projects is so "fun" to debug. Yes, everyone can be a super coder on his little bubble and use all the latest techniques to write high quality code, the problems arise when his/her bubble needs to interact with an ocean of unseen bubbles, many of which tainted ones.
- ethbro 10y ago
  The longer I've coded in practice, the more suspicious I've gotten about "you don't need any domain knowledge, here are perfect specifications" approaches. The fingers on the keyboard should always have some grasp of the bigger picture, or bad things are likely to happen.
  - pjmlp 10y ago
    Fully agree, I never understood the stereotype of coder closed in a cubicle breaking LOC records, coding without any other knowledge than programing language and libraries. I always have spent a big part of my time interacting with those that would eventually use the programs/libraries. Without domain knowledge and communication skills, there is a high probability of misunderstandings.