4 ms·

I didn't understand that part. It describes "high data rate" as "best case". Does "better than we ever imagined" means they were overflowing in good usable da

by kzhahou 11y ago

I didn't understand that part. It describes "high data rate" as "best case". Does "better than we ever imagined" means they were overflowing in good usable data? Because too much data sounds like a problem. Unrelated, note how difficult it is for people to accept 100% responsibility for a problem. For example: > Did we (the JPL team) make an error in assuming how the select/pipe mechanism would work ? Yes, probably. There's no "probably"! A mistake was clearly made.

msh 11y ago
Well, the properly might refer to if it was reasonable to make that assumption.
duaneb 11y ago
This is science, all knowledge is both inductively reached and imperfect. More people should use the word "probably"—if you're going to assign blame, which is not always necessary, it is important to do so accurately.
- reagency 11y ago
  Everything is probability. Why since out some statements as deserving of qualification? You said all knowledge is inductively reached, why didn't you say "probably"?!
- deleted 11y ago
  [deleted]
astrodust 11y ago
Programmers and lawyers are notorious for adding conditions to their statements to avoid liability. "Will this be done Thursday?" If you answer with a confident "yes" you're going to learn the cost of commitment when an unknown bites you in the ass. It's always about degrees of probability.
kmill 11y ago
There are (at least) two ways of reading this. The first is probably how you are reading it: the assumption caused an error. In this case, it is probably not a "probably," since an error did indeed occur. A second way to read it is whether it was an error on their part to make the assumption, and that is harder to say since they could have just been following the data they had on hand (a "you couldn't have known" scenario).
monknomo 11y ago
I think he's speaking from the perspective of the mission, not from the perspective of the computer. From a mission perspective, overflowing with data is a good place to be. From a computer perspective, overflowing with data is a problem that needs management.
deleted 11y ago
[deleted]
laumars 11y ago
what I find weirder is how quick people are to assign 100% blame when 99.9% of the time several people could have detected or prevented the problem. People work as a team - in fact often teams of teams - yet we assign blame to individuals.
- Bahamut 11y ago
  I experienced a layoff as a result of this once - essentially the product development cycle at this company did not properly account for implemenation, much less scaling for clients' use cases. QA was flawed as a result, and products shipped buggy. Deploys were based on releasing new features or for bug fixes for bugs that important people within clients noticed. The process ended up with me accidentally releasing a broken Android apk to production, and I ended up falling on the sword with no one else taking responsibility for the resulting quality. Needless to say, that company bled a lot of high quality developers as a result, somehow turning a likely success to likely failure. Startups should beware of such behavior - it is a great way to cause the company to self-destruct when you are not giving all stakeholders adequate say on deliverables.

by kzhahou 11y ago

msh 11y ago

Well, the properly might refer to if it was reasonable to make that assumption.

duaneb 11y ago

This is science, all knowledge is both inductively reached and imperfect. More people should use the word "probably"—if you're going to assign blame, which is not always necessary, it is important to do so accurately.

reagency 11y ago
Everything is probability. Why since out some statements as deserving of qualification? You said all knowledge is inductively reached, why didn't you say "probably"?!
deleted 11y ago
[deleted]

astrodust 11y ago

Programmers and lawyers are notorious for adding conditions to their statements to avoid liability. "Will this be done Thursday?" If you answer with a confident "yes" you're going to learn the cost of commitment when an unknown bites you in the ass. It's always about degrees of probability.

kmill 11y ago

There are (at least) two ways of reading this. The first is probably how you are reading it: the assumption caused an error. In this case, it is probably not a "probably," since an error did indeed occur. A second way to read it is whether it was an error on their part to make the assumption, and that is harder to say since they could have just been following the data they had on hand (a "you couldn't have known" scenario).

monknomo 11y ago

I think he's speaking from the perspective of the mission, not from the perspective of the computer. From a mission perspective, overflowing with data is a good place to be. From a computer perspective, overflowing with data is a problem that needs management.

deleted 11y ago

[deleted]

laumars 11y ago

what I find weirder is how quick people are to assign 100% blame when 99.9% of the time several people could have detected or prevented the problem. People work as a team - in fact often teams of teams - yet we assign blame to individuals.

Bahamut 11y ago
I experienced a layoff as a result of this once - essentially the product development cycle at this company did not properly account for implemenation, much less scaling for clients' use cases. QA was flawed as a result, and products shipped buggy. Deploys were based on releasing new features or for bug fixes for bugs that important people within clients noticed. The process ended up with me accidentally releasing a broken Android apk to production, and I ended up falling on the sword with no one else taking responsibility for the resulting quality. Needless to say, that company bled a lot of high quality developers as a result, somehow turning a likely success to likely failure. Startups should beware of such behavior - it is a great way to cause the company to self-destruct when you are not giving all stakeholders adequate say on deliverables.