Error 33: Difference between revisions
No edit summary |
m →top: General fixes, added orphan tag |
||
| (3 intermediate revisions by 2 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 |
||
| ⚫ | 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== |
||
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).