Hacker News Reader

Comment by geuis | Hacker News Reader

Understand the type of organization NASA is. First, accountability is everything. It's not that there are big internal political struggles (there are), but more importantly accountability is required for high safety. We aren't talking about a 10 person startup where a bad commit to production takes down a site for a few hours. We're talking about people's lives, careers, and the safety of millions of people that could be negatively affected by a crash or explosion.

When he talks about it being their fault, it's not that those engineers are being singled out for punishment and derision. They had to find out where the problem existed that led to the loss of Columbia, and after extremely thorough testing they believed it existed with the foam team. It's simply a matter of finding where a problem is and doing everything you can to fix it.

So it's not a personal, vindictive "your fault", its an impersonal "the problem is here, lets fix it".

View on HN

> accountability is required for high safety

It's not. That's complete bullshit, and the On-Board Software Group demonstrated it by being as flawless as can be during the whole history of the Shuttle: as far as I know there was no personal accountability in the OSG, the only thing accountable was The Process supported by a strong culture of adversarial testing.

Personal accountability in such a system brings politics and career advancement in focus and leads to issues being shoved under the rug when inconvenient and energy being expended in finger-pointing and blame games rather than fixing problems.

> So it's not a personal, vindictive "your fault", its an impersonal "the problem is here, lets fix it".

No, it's not. Accountability is very precisely "your fault", that's all it is. That's pretty much the definition of it.

There may not have appeared to have been any personal accountability, but make no mistake if anything had gone wrong with the On-Board Software the EXACT same accountability process would have been initiated to ensure that the same human error did not occur for a second time.

Very unlikely, unless that had been imposed on the group by an external, blame-oriented entity.

Left to its own devices, the group would most certainly have operated as it did every time it found fault in its output: find out how The Process had allowed for a fault to be introduced and reach output, find out how to make The Process prevent the introduction and/or release of such faults, fix The Process.

So no, the "exact same accountability process" would most definitely not have been initiated within the group, a very different one would have taken place.

> No, it's not. Accountability is very precisely "your fault", that's all it is. That's pretty much the definition of it.

That. Accountability (worse: "personal accountability" and variants thereof) are a tool provided by the law to determine who to recover damages from after a failure has occurred. It is entirely unsuitable for failure prevention because it is entirely orthogonal to rigorous testing and a culture of workplace safety.

Anyone who insists on accountability on their project does not know what they need. What they get is an extraordinary amount of ass-covering, finger-pointing and blame deflection, though.

That's a really good summary of mission critical systems accountability problem.

Reply on news.ycombinator.com