Error 33: Difference between revisions
Canis Lupus (talk | contribs) m Orphaned page, tagging |
|||
| Line 4: | Line 4: | ||
==Origin== |
==Origin== |
||
"Error 33" was originally coined by [[George Pake|Dr. George Pake]], the first director of [[Xerox Parc]].<ref name="Web 2.0 Meets Error 33"/> |
"Error 33" was originally coined by [[George Pake|Dr. George Pake]], the first director of [[Xerox Parc]].<ref name="Web 2.0 Meets Error 33"/> |
||
Visit Error33.net This msg is brout to you by Gunslinger of Error33.net, O and Renagade Is The Master |
|||
==Usage== |
==Usage== |
||
Revision as of 18:49, 27 June 2009
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 into the critical path of another project.[1][2]
Origin
"Error 33" was originally coined by Dr. George Pake, the first director of Xerox Parc.[3] Visit Error33.net This msg is brout to you by Gunslinger of Error33.net, O and Renagade Is The Master
Usage
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 to make sure that as many dependencies as possible use established technology, engineering, or research results.
Xerox 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. Alan 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, Alan 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]
Another Xerox alumnus, Neil Gunther, 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
- ^ "Datasegment Online Dictionary
- ^ Eric S Raymond's Online Jargon File
- ^ a b Gunther, Neil (2008). "Web 2.0 Meets Error 33".
- ^ a b Kay, Allan (2004). "The Power Of The Context" (Draper Prize Lecture, Feb 24, 2004 VPRI Research Note RN-2004-001).