Error 33: Difference between revisions
fixed ref punct |
m →top: General fixes, added orphan tag |
||
| (20 intermediate revisions by 18 users not shown) | |||
| Line 1: | Line 1: | ||
{{Orphan|date=December 2021}} |
|||
| ⚫ | The term "'''error 33'''" is [[jargon]] for the failure due to predicating one research project on the success of another, or alternatively for allowing one's own research |
||
| ⚫ | The term "'''error 33'''" is [[jargon]] for the failure due to predicating one research project on the success of another, or alternatively for allowing one's own research project to be on the critical path of another project.<ref name="datasegment">[http://onlinedictionary.datasegment.com/word/error%2033 "Datasegment Online Dictionary]{{Dead link|date=December 2019 |bot=InternetArchiveBot |fix-attempted=yes }}</ref><ref name="jargonfile">[[Eric S Raymond]]'s [http://catb.org/esr/jargon/html/E/error-33.html Online Jargon File]</ref> |
||
==Origin== |
==Origin== |
||
"Error 33" was originally coined by [[ |
"Error 33" was originally coined by [[George Pake]], the first director of [[Xerox Parc]].<ref name="Web 2.0 Meets Error 33"/> |
||
==Usage== |
==Usage== |
||
As alumni of |
As alumni of Xerox Parc have spread to other companies throughout [[Silicon Valley]], this phrase has been broadened in scope to general research and engineering projects as well as research efforts. |
||
The advice to leaders of any project with a substantial development risk is |
The advice to leaders of any project with a substantial development risk is ensure that as many dependencies as possible use established technology, engineering, or research results. |
||
Xerox Parc alumnus [[Alan Kay]] has elaborated this into two "sets of theories" that contradict each other.<ref name="The Power Of The Context">Kay, Alan (2004). [http://www.vpri.org/pdf/m2004001_power.pdf "The Power Of The Context"] (Draper Prize Lecture, Feb 24, 2004 ''VPRI Research Note RN-2004-001'').</ref> In one direction, avoidance of error 33 suggests that teams avoid building their own tools - in his example, software languages and operating systems - because it can sink an incredible amount of time that doesn't move the primary project objective forward. In the opposite direction, error 33 is avoided by creating exactly the right tools for the job at hand, and avoiding reliance upon external [[vendor]]s, teams, or projects for success. Kay cites the development of [[Ethernet]] as an example of avoiding error 33: [[Robert Metcalfe|Metcalfe]], [[David Boggs|Boggs]], [[Butler Lampson|Lampson]], and [[Charles P. Thacker|Thacker]] avoided designing a protocol that depended upon an error-free network, and instead depended upon retry and recovery in a way that eventually would send messages perfectly, even under extreme conditions. |
|||
In the same paper, |
In the same paper, Kay cites the [[Bravo (software)|Bravo text editor]] (precursor to [[Microsoft Word]]) as a project that delivered [[WYSIWYG]] printing, but avoiding dependence on a reliable platform by incorporating the ability to replay right up to the point of a crash.<ref name="The Power Of The Context"/> |
||
[[Neil Gunther]], also a Xerox Parc alumnus, suggests that [[Web 2.0]] sites that depend heavily for their commercial success upon [[Amazon.com]]'s (at the time of writing in 2008) barely-out-of-research [[Elastic Compute Cloud]] (EC2) technology is just such an error 33.<ref name="Web 2.0 Meets Error 33">Gunther, Neil (2008). [http://perfdynamics.blogspot.com/2008/02/web-20-meets-error-33.html "Web 2.0 Meets Error 33"].</ref> A February 2008 failure of Amazon's EC2 systems did impact many websites. |
|||
==References== |
==References== |
||
{{reflist}} |
{{reflist}} |
||
[[Category:Reliability engineering]] |
|||
Latest revision as of 08:29, 16 December 2021
The term "error 33" is jargon for the failure due to predicating one research project on the success of another, or alternatively for allowing one's own research project to be on the critical path of another project.[1][2]
Origin
[edit]"Error 33" was originally coined by George Pake, the first director of Xerox Parc.[3]
Usage
[edit]As alumni of Xerox Parc have spread to other companies throughout Silicon Valley, this phrase has been broadened in scope to general research and engineering projects as well as research efforts.
The advice to leaders of any project with a substantial development risk is ensure that as many dependencies as possible use established technology, engineering, or research results.
Xerox Parc alumnus Alan Kay has elaborated this into two "sets of theories" that contradict each other.[4] In one direction, avoidance of error 33 suggests that teams avoid building their own tools - in his example, software languages and operating systems - because it can sink an incredible amount of time that doesn't move the primary project objective forward. In the opposite direction, error 33 is avoided by creating exactly the right tools for the job at hand, and avoiding reliance upon external vendors, teams, or projects for success. Kay cites the development of Ethernet as an example of avoiding error 33: Metcalfe, Boggs, Lampson, and Thacker avoided designing a protocol that depended upon an error-free network, and instead depended upon retry and recovery in a way that eventually would send messages perfectly, even under extreme conditions.
In the same paper, Kay cites the Bravo text editor (precursor to Microsoft Word) as a project that delivered WYSIWYG printing, but avoiding dependence on a reliable platform by incorporating the ability to replay right up to the point of a crash.[4]
Neil Gunther, also a Xerox Parc alumnus, suggests that Web 2.0 sites that depend heavily for their commercial success upon Amazon.com's (at the time of writing in 2008) barely-out-of-research Elastic Compute Cloud (EC2) technology is just such an error 33.[3] A February 2008 failure of Amazon's EC2 systems did impact many websites.
References
[edit]- ^ "Datasegment Online Dictionary[permanent dead link]
- ^ Eric S Raymond's Online Jargon File
- ^ a b Gunther, Neil (2008). "Web 2.0 Meets Error 33".
- ^ a b Kay, Alan (2004). "The Power Of The Context" (Draper Prize Lecture, Feb 24, 2004 VPRI Research Note RN-2004-001).