NDICE
Pgina 2 de 37
Pgina 3 de 37
Bill Park, Profesor de Fsica en la Universidad de Silicon Valley. Confirm que Randy Samuels
malinterpret las ecuaciones de la dinmica del robot.
Randy Samuels, programador. Escribi el cdigo del programa que caus que el robot Robbie
CX30 oscilara con gran amplitud, matando a su operador, Bart Matthews.
Sam Reynolds, Gerente de Proyecto del CX30, Ray Johnson era su superior inmediato. Su
experiencia fue adquirida en el campo de procesamiento de datos, pero fue puesto al mando
del proyecto CX30, muy a su pesar. Estaba a favor de aplicar el modelo de cascada del
desarrollo de software.
Robbie CX30, el robot. Robbie jams tuvo un mal pensamiento hacia nadie, aun as se torn
en un salvaje asesino.
Wesley Silber, Profesor de Ingeniera de Software en la Universidad de Silicon Valley. Condujo
una revisin de los procedimientos de aseguramiento de la calidad en Silicon Techtronics.
Sharon Skinner, profesora de Psicologa del Software en la Universidad de Silicon Valley. Vea
a Randy Samuels como una persona aplicada a su tarea, susceptible por dems a las crticas.
Valerie Thomas, Abogada, contratada por Sam Reynolds.
Michael Waterson, Presidente y Presidente Ejecutivo de Silicon Techtronics. Puso a Sam
Reynolds a cargo del proyecto Robbie CX30 como una medida para recortar gastos.
Contribuy generosamente a la campaa de reeleccin de Jane McMurdock. Contrat al Dr.
Silber para llevar adelante una investigacin sobre aseguramiento de calidad en Silicon
Techtronics.
Max Worthington, Jefe de Seguridad de Silicon Techtronics. Monitoreaba la comunicacin
electrnica entre empleados y as descubri a Cindy Yardley.
Ruth Whiterspoon, analista programadora y vocera del comit Justicia para Randy Samuels.
Defenda a Randy Samuels sobre la base de que Silicon Techtronics estaba legalmente obligada
a entregar un robot confiable y seguro.
Cindy Yardley, empleada y probadora de software de Silicon Techtronics. Admiti la
falsificacin de pruebas de software con el fin de resguardar el puesto de trabajo de sus
compaeros.
Harry Yoder, Profesor de Tecnologa de Computacin y tica. Examin, en una entrevista
publicada en la revista dominical del SENTINEL-OBSERVER, la tensin entre las
responsabilidades individuales y corporativas.
Pgina 4 de 37
Pgina 5 de 37
principal era que Johnson y otros miembros a nivel directivo no entendan que el Robbie
CX30 era fundamentalmente diferente de versiones anteriores del robot. Estas fuentes
dijeron al SENTINEL-OBSERVER que los nuevos empleados no estaban totalmente integrados al
proyecto, an seis meses despus de su ingreso, cuando diez robots Robbie CX30, incluido al
robot que mat a Bart Matthews, ya haban sido despachados. Segn Marta, Sam slo quera
mantener las cosas lo ms simples posible. No quera que el nuevo personal complicara las
cosas. Se pasaron seis meses leyendo manuales. La mayora de los empleados nuevos no
saban nada de robots y Sam no estaba como para perder su tiempo tratando de ensearles.
Segn Marta, la reunin del 12 de junio se hizo famosa en la corporacin Silicon Techtronics
porque fue en esa reunin donde Ray Johnson anunci su Teora Ivory Snow [no existe el
blanco perfecto, o bien, no hay blanco ms blanco que el blanco nieve] de diseo y desarrollo
de software. De acuerdo a Marta, Ray (Johnson) nos dio una gran presentacin en multimedia, con diapositivas y todo. La esencia de esta Teora Ivory Snow es simplemente que el
blanco nieve es 99,44 porciento puro y que no hay razn por la que el software de robtica
deba ser ms puro que esto. Dijo repetidas veces que El software perfecto era un oxmoron .
Marta y otros personajes annimos que se acercaron con informacin, retrataron a Johnson
como un gerente con una desesperada necesidad de ser ayudado por un xito en el proyecto.
Versiones anteriores de Robbie, CX10 y CX20, fueron experimentales en naturaleza y nadie
esperaba que fueran xitos comerciales. De hecho, la Divisin Robtica de Silicon Techtronics
estaba operando con sus finanzas en rojo desde su concepcin seis aos atrs. O triunfaba el
CX30 o Silicon Techtronics quedara fuera del negocio de robtica industrial. Los robots
Robbie anteriores tuvieron mucha prensa, especialmente ac en Silicon Valley, dijo otra
fuente que tambin quiere permanecer annima. Robbie CX30 iba a capitalizarse con la
buena publicidad generada por los proyectos anteriores. Lo nico es que Robbie CX30 era
ms revolucionario de lo que Johnson quera admitir. CX30 representaba un paso gigante
hacia adelante en trminos de sofisticacin. Haba muchsimas preguntas acerca de los
parmetros industriales en los que debera trabajar el CX30. Mucho de lo que deba ejecutar
era completamente nuevo, pero Johnson nunca lo pudo entender. l slo nos vea como unos
perfeccionistas. Uno de sus dichos favoritos era La perfeccin es la enemiga de lo bueno .
Pgina 7 de 37
un robot Robbie CX30 operativo para el 1 de enero de este ao. Sam Reynolds no pudo ser
ubicado para entrevistarlo ya sea sobre su rol en el incidente o sobre Samuels y sus hbitos en
el trabajo.
ramos un equipo democrtico, a excepcin del liderazgo provisto por Sam (Reynolds),
observ otro miembro del equipo. En el mundo del desarrollo de software, un equipo
democrtico es un equipo en donde todos los miembros de ste tienen un decir igual en el
proceso de toma de decisiones. Desafortunadamente, nosotros ramos un equipo de
individualistas muy ambiciosos, muy talentosos - si debo referirme a m mismo - y muy
opinadores. Randy (Samuels) era justo el peor del grupo. Lo que quiero decir es que tenamos,
por ejemplo, a dos chicos y a una chica con grados de maestra de la CMU, y no eran tan
arrogantes como Randy.
CMU significa Universidad de Carnegie-Mellon, una lder nacional en enseanza de
ingeniera de software.
Un compaero coment sobre un incidente que Samuels caus en una reunin de
aseguramiento de la calidad. Esta reunin involucraba a Samuels y a tres revisores de un
mdulo de software que Samuels haba diseado e implementado. Tales reuniones son
llamadas revisiones de cdigo. Uno de los revisores mencion que Samuels haba usado un
algoritmo sumamente ineficiente (programa) para lograr un determinado resultado y Samuels
se puso todo colorado. Empez a gritar una sarta de obscenidades y despus se levant y se
fue. Y nunca regres.
Le enviamos un memo con un algoritmo ms rpido y a su tiempo us este algoritmo en su
mdulo, agreg el colega.
El mdulo de software del incidente de la reunin de aseguramiento de la calidad fue el
primero en ser identificado como una falla en el asesino del operador de robot. No obstante,
este colega se apur a sealar que la eficacia del algoritmo no era un tpico en el
malfuncionamiento del robot. Era slo que Randy haca muy difcil para la gente el poderle
comunicar las observaciones. Se tomaba todo muy a pecho. Se gradu con el puntaje ms alto
de su clase y luego se recibi con honores en ingeniera de software en Purdue.
Definitivamente es muy inteligente.
Randy, en su pared, tiene este inmenso cartel hecho en Banner, continu este colega,
Deca, DENME LA ESPECIFICACIN Y LES DAR EL PROGRAMA DE COMPUTACIN. Ese
es el tipo de arrogancia que tena y tambin demuestra que tena muy poca paciencia para
desarrollar y verificar las especificaciones. Amaba el aspecto de solucionar el problema, la
programacin propiamente dicha. No pareciera que Randy Samuels qued atrapado en el
espritu de la programacin sin egolatra, observ la Profesora Skinner cuando escuch esta
parte de la entrevista con los colegas de trabajo de Samuels. La idea de una programacin sin
egocentrismo es que el producto de software pertenece al equipo y no a los programadores
individuales. La idea es estar abierto a las crticas y estar menos atado al trabajo propio.
Ciertamente que la tarea de revisin de cdigo es coherente con esta filosofa en general.
Una colega habl acerca de otro aspecto de la personalidad de Samuels: su capacidad de
ayuda. Randy odiaba las reuniones, pero era muy bueno con las relaciones de uno a uno.
Siempre estaba ansioso por ayudar. Recuerdo una vez que me encontraba encerrada en un
camino sin salida y l, en vez de tan slo sealarme la direccin correcta, se hizo cargo del
problema y lo resolvi l mismo. Se pas cerca de cinco das completos en mi problema. Por
supuesto que mirado en retrospectiva, hubiera sido mejor para el pobre Sr. Matthews y su
familia que Randy se hubiese dedicado tan slo a sus propias cosas, agreg luego de una
larga pausa.
Pgina 9 de 37
Pgina 10 de 37
En una conversacin con este diario, Anderson dijo que Samuels no tena mucho para decir
sobre la controversia cascada-prototipo, pero s afirm que dara una mano con tal que
exoneraran a Samuels.
El proyecto fue sentenciado a muerte mucho antes que Samuels malinterpretara esas
frmulas, aclar Anderson enfticamente en la sala de su casa en los suburbios.
En conversacin con este diario, Anderson hizo lo mejor de s para explicar la controversia del
mtodo cascada vs. prototipo en trminos simples. El punto principal en realidad era si
podamos llegar a ponernos de acuerdo en los requerimientos del sistema sin dejar que los
operadores del robot presintieran lo que tenamos en mente. Reynolds ha estado en el negocio
de procesamiento de datos por tres dcadas y es bueno en eso, pero nunca debera haber sido
el gerente de este proyecto.
Conforme a registros obtenidos por el SENTINEL-OBSERVER, Silicon Techtronics transfiri a
Sam Reynolds de la Divisin Procesamiento de Datos, que se encargaba de inventario y
salarios, a la Divisin Robtica, justo tres semanas antes de la reunin del 11 de diciembre a
que alude Anderson en su memo.
Reynolds fue transferido a la Divisin Robtica por el presidente de Silicon Techtronics,
Michael Waterson. Reynolds reemplazaba a John Cramer, quien gerenciaba el anterior
proyecto Robbie CX10 y CX20. Cramer fue puesto a cargo del proyecto CX30, pero muri
inesperadamente en un accidente areo. Al colocar a Reynolds a cargo del proyecto CX30, nos
dice nuestra fuente, que Waterson iba en contra del consejo de Ray Johnson, Jefe de la
Divisin Robtica. De acuerdo con estas fuentes, Johnson se opona fuertemente a la
alternativa de ponerlo a Reynolds como jefe del proyecto Robbie CX30. Estas fuentes dijeron al
SENTINEL-OBSERVER que la eleccin de Waterson por Reynolds fue puramente una decisin
de recorte de gastos. Era ms barato transferir a Reynolds a la Divisin Robtica que
incorporar a un nuevo lder de proyecto fuera de la corporacin.
La fuente annima que el SENTINEL-OBSERVER llamar Marta describi la situacin de este
modo: Waterson pensaba que sera ms barato transferir a Reynolds a robtica antes que
intentar encontrar afuera un nuevo gerente para el proyecto Robbie. Adems, Waterson
tenda a sospechar de la gente de afuera del grupo. Con frecuencia mandaba memos sobre
cunto tarda la gente en aprender el modo de hacer las cosas de Silicon Techtronics. Desde
el punto de vista de Waterson, Reynolds era el gerente y fue transferido a su nuevo puesto en
Robtica como un gerente y no como un experto tcnico. Claramente, Reynolds se vea a s
mismo tanto gerente como experto tcnico. Reynolds no tena conciencia de sus propias
limitaciones tcnicas.
Segn Marta, Reynolds era muy renuente a gerenciar un proyecto que no usara el modelo de
cascada que tan bien le haba servido en el procesamiento de datos. Tild al modelo prototipo
como un modelo de moda en la reunin del 11 de diciembre, y despus de una serie de
intercambios verbales la cosa se puso muy personal.
Anderson estaba especialmente expresiva, recuerda Marta. Tena mucha experiencia con
interfaces con usuarios y desde su perspectiva, la interfaz robot-operador era crtica para el
xito del CX30, dado que la intervencin del operador sera frecuente y a veces crtica. En
su entrevista con el SENTINEL-OBSERVER, Jan Anderson coment sobre este aspecto de la
reunin del 11 de diciembre:
Reynolds estaba en contra de perder el tiempo - para usar sus propias palabras - con
cualquier tipo de anlisis formal de las propiedades de los factores humanos y su interfaz con
el usuario. Para l, las interfaces con el usuario real eran un tema perifrico.
Pgina 11 de 37
Para l [Reynolds], cualquier cosa nueva era moda, agrega Anderson. Las interfaces de la
computadora eran una moda, el diseo orientado a objetos era una moda, la especificacin
formal y las tcnicas de verificacin eran una moda, y por sobre todo, el modelo prototipo era
una moda.
Justo una semana despus de la reunin del 11 de diciembre, el grupo del proyecto Robbie
recibi un memo de Sam Reynolds concerniente al plan para el proyecto Robbie CX30.
Era el modelo de cascada, como salido de un libro, Anderson dijo a este reporter mientras
revisaba una copia del memo con el plan del proyecto. Anlisis de requerimientos y
especificacin, luego diseo de arquitectura y diseo detallado, codificacin, prueba, entrega
y mantenimiento. En el modo de ver de Reynolds, no haca falta tener ninguna interaccin del
usuario con el sistema hasta muy, pero muy avanzado el proyecto. El SENTINEL-OBSERVER se
ha enterado de que el primer operador que realmente us el robot Robbie CX30 en una
funcin industrial fue Bart Matthews, el hombre que fue muerto en la tragedia del robot
asesino. Este primer uso de Robbie CX30 en un uso industrial fue cubierto por los medios,
incluyendo este peridico. Como una gran irona, El Informe Anual de Silicon Techtronics
para los Accionistas, publicado el pasado mes de marzo, contiene en la brillante portada una
foto de un sonriente Bart Matthews. A Matthews se lo muestra operando al mismsimo robot
Robbie CX30 que lo aplast hasta la muerte tan solo dos meses despus de la toma fotogrfica.
Pgina 12 de 37
eventos inusuales tales como datos extraos desde los sensores del robot, movimiento errtico
o violento del robot o error del operador. Fue justamente esa condicin excepcional la que
llev a la muerte a Bart Matthews.
Estos prrafos fueron extractados de las porciones del documento de requerimientos que trata
sobre los requerimientos no funcionales. Los requerimientos no funcionales listan en
detalle las restricciones bajo las cuales operara el robot. Por ejemplo, el requerimiento de que
el robot sera incapaz de daar a su operador humano es una restriccin y Silicon
Techtronics, segn Ruth Whiterspoon, estaba legalmente obligada a satisfacer este punto. La
parte de los requerimientos funcionales del documento de requerimientos cubre (nuevamente
en sumo detalle) el comportamiento del robot y su interaccin con el entorno y su operador
humano. En particular, los requerimientos funcionales especificaban el comportamiento del
robot bajo cada una de las condiciones excepcionales esperadas. En su declaracin a los
periodistas en la conferencia de prensa, Whiterspoon explic que Bart Matthews fue muerto
cuando se produjo la condicin excepcional 5.2.4.26. sta involucra un movimiento del brazo
del robot extremadamente violento e impredecible. Esta condicin requiere de la intervencin
del operador, a saber el ingreso de los cdigos de comando mencionados en el documento,
pero aparentemente Bart Matthews se confundi y no pudo ingresar con xito estos cdigos.
Si bien el programa de Randy Samuels estaba mal - l en verdad malinterpret las frmulas
de la dinmica del robot, como se inform a los medios. La condicin excepcional 5.2.4.26
estaba diseada para protegerse de justamente este tipo de contingencia, dijo Whiterspoon a
los periodistas. Los valores del movimiento del robot generados por el programa de Randy
identificaron correctamente a esta condicin excepcional y el operador del robot recibi el
debido aviso de que algo andaba mal.
Whiterspoon dijo que posea una declaracin firmada de otro operador de robot de
Cybernetics en donde afirmaba que las sesiones de entrenamiento ofrecidas por Silicon
Techtronics nunca mencionaron a sta ni a tantas otras condiciones excepcionales. Segn
Whiterspoon, el operador del robot ha jurado que ni a l ni a ningn otro operador de robot
les fue dicho jams que el brazo del robot poda oscilar violentamente.
Whiterspoon cit esta declaracin en la conferencia de prensa. Ni yo ni Bart recibimos
entrenamiento para manejar este tipo de condicin excepcional. Dudo mucho que Bart
Matthews tuviese idea de qu se supona deba hacer cuando la pantalla de la computadora
comenz a mostrar el mensaje de error.
Las condiciones excepcionales que requieren de la intervencin del operador causan un
mensaje de error que se genera en la consola del operador. La Polica de Silicon Valley
confirm que cuando Bart Matthews fue muerto, el manual de referencia en su consola estaba
abierto en la pgina del ndice que contena los cdigos de ingreso para los errores.
Witherspoon luego cit secciones del documento de requerimientos que obligan a Silicon
Techtronics (el vendedor) a entrenar adecuadamente a los operadores de robots:
El vendedor suministrar cuarenta (40) horas de entrenamiento para los operadores. Este
entrenamiento cubrir todos los aspectos de la operacin del robot, incluyendo una cobertura
exhaustiva de los procedimientos de seguridad que deben seguirse en caso de condiciones
excepcionales que contengan potencialmente el riesgo de dao corporal. El vendedor
proveer y administrar instrumentos de prueba apropiados que sern usados para certificar
el suficiente entendimiento del operador de las operaciones de la consola del robot y de los
procedimientos de seguridad. Slo los empleados del cliente que hayan pasado estas pruebas
estarn habilitadas para operar el robot Robbie CX30 en una verdadera funcin industrial.
El manual de referencia deber suministrar instrucciones claras para la intervencin del
operador en todas las situaciones excepcionales, especialmente e inclusive aquellas que
contengan potencialmente el riesgo de dao corporal.
Pgina 14 de 37
Pgina 15 de 37
1.
Introduccin
2.
Mi evaluacin de la interfaz con el usuario del Robbie CX30 est basada en las ocho reglas
de oro de Shneiderman (4). Tambin utilic otras tcnicas para evaluar la interfaz, pero stas
sern publicadas en papers separados. En esta seccin ofrezco una breve revisin de las ocho
reglas de oro de Shneiderman, un tema que resultar ms familiar para expertos en interfaces
de computacin como yo y no a hackers de robtica que leyeron este oscuro peridico.
Las ocho reglas de oro son:
Pgina 16 de 37
1.
2.
3.
4.
5.
6.
7.
8.
3.
Buscar siempre la coherencia. Tal como se puede ver ms abajo, es importante que una
interfaz con el usuario sea coherente a muchos niveles. Por ejemplo, los diseos de
pantalla deben ser coherentes de una pantalla a la siguiente. En un entorno en que se
usa una interfaz grfica con el usuario (GUI), esto tambin implicar concordancia de
un utilitario al siguiente.
Permitirle a los usuarios frecuentes el uso de shortcuts. Los usuarios frecuentes (o,
power users) pueden desalentarse ante tediosos procedimientos. Permitirle a estos
usuarios un procedimiento menos tedioso para completar una tarea dada.
Dar realimentacin de informacin. Los usuarios necesitan ver las consecuencias de sus
acciones. Si un usuario ingresa un comando pero la computadora no muestra ya sea que
lo est procesando o lo ha procesado, esto puede dejar al usuario confundido o
desorientado.
Disear dilogos que tengan un fin. Interactuar con una computadora es algo as como
dialogar o conversar. Cada tarea debe tener un inicio, un desarrollo y un fin. Es
importante que el usuario sepa cundo una tarea est finalizada. El usuario necesita
tener la sensacin de que la tarea ha alcanzado su trmino.
Permitir manejos simples de los errores. Los errores del usuario deben estar diseados
dentro del sistema. Otro modo de decirlo es que no debe haber ninguna accin por
parte del usuario que sea considerada como un error que est ms all de la capacidad
del sistema para manejarlo. Si el usuario comete un error, debe recibir informacin til,
clara y concisa sobre la naturaleza de tal error. Debe resultar fcil para el usuario
deshacer este error.
Permitir deshacer las acciones con facilidad. Ms genricamente, los usuarios deben
poder deshacer lo que han hecho, sea sto o no de naturaleza errnea.
Respaldar que el centro del control est internamente. La satisfaccin del usuario es alta
cuando el usuario tiene la sensacin de que es l o ella quien tiene el control y la
satisfaccin del usuario es baja cuando el usuario siente que la computadora tiene el
control. Disear interfaces para reforzar la sensacin de que es en el usuario donde yace
el control en el mbito de la interaccin humano-computadora.
Reducir la carga de la memoria inmediata. La memoria inmediata del ser humano es
notablemente limitada. Los psiclogos regularmente citan a la ley de Miller que dice que
la memoria inmediata est limitada a siete piezas discretas de informacin. Hacer todo lo
posible para liberar la carga en la memoria del usuario. Por ejemplo, en lugar de pedirle
al usuario que tipee el nombre de un archivo para abrirlo, presentar al usuario una lista
de archivos disponibles en ese momento.
La interfaz del operador de Robbie CX30 viol todas y cada una de las reglas de Shneiderman.
Muchas de estas violaciones fueron directamente responsables del accidente que termin con
la muerte de un operador de robot.
La consola del robot era una IBM PS/2 modelo 55SX con un procesador 80386 y un monitor
EGA color con resolucin 640 x 480. La consola tena un teclado, pero no mouse. La consola
estaba empotrada en una estacin de trabajo que tena, adems, estantes para manuales y un
rea para tomar notas y para leer manuales. No obstante, el rea para escribir/leer estaba a
bastante distancia de la pantalla de la computadora, o sea que era bastante incmodo y
cansador para el operador manejar cualquier tarea que requiriera de mirar algo en el manual
y luego actuar rpidamente con respecto al teclado de la consola. La silla del operador estaba
deficientemente diseada y estaba demasiado alta con respecto a la posicin de la consola y al
rea de escribir/leer. Esto resenta mucho la espalda del operador y tambin causaba excesivo
cansancio de la vista.
Pgina 17 de 37
No puedo comprender cmo un sistema sofisticado como este no pudo incluir un aparato de
mejor diseo para los ingresos de los datos. Uno slo podra concluir que Silicon Techtronics
no tena mucha experiencia en tecnologa de interfaces con el usuario. El documento de
requerimientos (5) especificaba un sistema manejado por menes, lo cual era una eleccin
razonable. Sin embargo, en un utilitario en donde lo escencial era la rapidez, especialmente
cuando la seguridad del operador estaba en juego, el uso de un teclado para todas las tareas
de seleccin de opcin de menes fue una eleccin de extremada pobreza, que requera de
mucho uso del teclado para lograr el mismo efecto que poda haberse conseguido casi
instantneamente mediante un mouse. (Ver el paper escrito por Foley et al. (6) En realidad, se
me ocurrieron todas estas ideas antes que Foley las publicara, pero l me gan).
El operador del robot poda interactuar con el robot y de este modo producir un impacto
sobre su comportamiento al hacer las opciones en un sistema de menes. El men principal
consista de 20 temes, demasiados en mi opinin, y cada tem del men principal tena un
submen tipo desplegable asociado a ste. Algunos de los submenes tenan tanto como veinte
temes - nuevamente, demasiados. Es ms, pareca haber muy poca rima o razn en cuanto a
por qu los temes de los menes estaban listados en el rden en que lo estaban. Hubiese sido
mucho mejor una organizacin alfabtica o funcional.
Algunos del los temes en los menes desplegables tenan hasta cuatro menes pop up
relacionados a stos. stos apareceran en secuencias a medida que se haca la seleccin
correspondiente en los submenes. Ocasionalmente, una eleccin de un submen abrira un
cuadro de dilogo en la pantalla. Un cuadro de dilogo requiere de cierto tipo de interaccin
entre el operador y el sistema, por ejemplo para resolver ciertos temas, como ser, ingresar
cul es el dimetro de un dispositivo dado a ser bajado en el bao de cido.
El sistema de menes presenta una estricta jerarqua de eleccin de menes. El operador
podra volver hacia atrs en esta jerarqua apretando la tecla de escape. Esta tecla escape
tambin podra terminar los dilogos.
El uso de color en la interfaz fue muy poco profesional. Haba demasiados colores en un
espacio demasiado chico. Los contrastes eran muy fuertes y el resultado, para este revisor,
result en una severa fatiga ocular en tan slo quince minutos de uso. Hubo uso excesivo de
efectos musicales tontos y flashes cuando se ingresaban opciones o cdigos errneos.
Uno debera preguntarse por qu Silicon Techtronics no intent un enfoque ms sofisticado
para el diseo de la interfaz. Luego de un cuidadoso estudio del dominio de los utilitarios del
Robbie CX30, he llegado a la conclusin de que una interfaz de manipulacin directa, que
mostrara literalmente al robot en la consola del operador, habra sido lo ideal. El entorno tan
visual dentro del cual operaba el robot se prestaba naturalmente al diseo de metforas de
pantalla apropiadas para ese entorno, metforas que el operador podra entender con
facilidad. Esto permitira que el operador manipulara el robot mediante el manejo, en la
consola del robot, de la representacin grfica del robot en su entorno. He solicitado a uno de
mis estudiantes en el doctorado, Susan Farnsworth, que investigara un poco ms esta
posibilidad.
4.
En qu modo la interfaz del robot Robbie CX30 viol las ocho reglas de oro
La intefaz con el usuario de Robbie CX30 viol todas y cada una de las reglas de oro en
diferentes modos. En este paper slo tratar unas pocas instancias de violaciones de reglas,
dejando la discusin ms en detalle para futuros artculos y mi prximo libro [NOTA AL PIE:
CODEPENDENCIA: Cmo los Usuarios de Computadoras permiten deficientes Interfaces con el
Usuario, Angst Press, Nueva York. Este libro presenta una teora radicalmente nueva con
respecto a la relacin entre la persona y su mquina. Esencialmente, algunas personas
Pgina 18 de 37
necesitan una interfaz de mala calidad a los fines de evitar ciertos problemas psicolgicos no
resueltos en sus vidas.]. Lo que har es destacar esas violaciones que fueron relevantes en este
accidente en particular.
4.1
En la interfaz del usuario de Robbie CX30 hubieron muchas incoherencias. Los mensajes de
error podan aparecer en casi cualquier color y podan estar acompaados por casi cualquier
tipo de efecto musical. Adems, los mensajes de error podan aparecer en casi cualquier lugar
de la pantalla.
Cuando Bart Matthews vio el mensaje de error de la condicin excepcional que ocurri luego,
la cual requera la intervencin del operador, es probable que fuera esa la primera vez que
vea ese mensaje en especial. Adems, el mensaje de error apareci en un cuadro verde, sin
ningn efecto de sonido. Este es el nico mensaje de error de todo el sistema que aparece en
verde y sin ningn tipo de acompaamiento de orquesta.
4.2
Este principio no aparece de ningn modo en todo el diseo de la interfaz. Por ejemplo,
hubiera sido una buena idea permitir que los usuarios frecuentes pudieran ingresar la
primera letra de la opcin de un submen o men en lugar de requerrseles el uso de las
teclas del cursor y luego la tecla enter para elegir esa opcin determinada. El mecanismo de
seleccin de menes de este sistema debe haber provocado al operador bastante fatiga mental.
Es ms, debera haberse permitido algn tipo de sistema de tipeo anticipado que permitiera al
usuario frecuente ingresar una secuencia de opciones de men sin tener que esperar a que
apareciera realmente el men en pantalla.
4.3
En muchos casos el usuario no tiene idea de si el comando que acaba de ingresar se est
procesando o no. Este problema se exagera adems por las inconsistencias en el diseo de la
interfaz con el usuario. En algunos casos al operador se le da una realimentacin detallada de
lo que el robot est ejecutando. En otros, el sistema permanece misteriosamente silencioso. En
general, al usuario se lo lleva a que espere algn tipo de realimentacin y por consiguiente se
queda confundido cuando sta no se le da. En la pantalla, no hay una representacin visual
del robot y su entorno, y la visin que tiene el operador del robot a veces est obstruida.
4.4
Hay muchos casos en los que una secuencia dada de tecleado representa una idea holstica,
una tarea completa, pero al operador se lo deja sin el tipo de realimentacin que le
confirmare que la tarea ha sido en efecto completada. Por ejemplo, hay un dilogo bastante
complicado que se necesita cuando se quiere sacar un elemento de un bao de cido. Sin
embargo, luego de completar este dilogo, el usuario es llevado a otro dilogo nuevo, y no
relacionado con ste, sin que se le informe que el dilogo anterior ha finalizado.
4.5
1Feedback
Pgina 19 de 37
El sistema pareciera estar diseado para que el usuario se lamentara por cualquier ingreso
errneo. No slo el sistema permite numerosas oportunidades para el error, sino que cuando
un error en realidad ocurre, es probable que no se repita por algn tiempo. Ello se debe a que
la interfaz con el usuario hace que recuperarse de un error sea una odisea tediosa, frustrante
y a veces enfurecedora. Algunos de los mensajes de error eran directamente ofensivos y
condescendientes.
4.6
Como se menciona en el prrafo anterior, la interfaz con el usuario hace muy dificil la tarea
de deshacer entradas errneas. En general, el sistema de menes permite deshacer facilmente
las acciones, pero esta filosofa no alcanza al diseo de los cuadros de dilogo y al manejo de
condiciones excepcionales. Desde un punto de vista prctico (opuesto al terico), la mayora
de las acciones son irreversibles cuando el sistema est en un estado de condicin excepcional,
y esto ayud a llegar a la tragedia del robot asesino.
4.7
Un sistema que se maneja por medio de menes es en general bueno en trminos de la carga
de memoria que crea en los usuarios. No obstante, hay una gran variacin entre
implementaciones particulares de sistemas de men en lo que hace a carga de memoria. La
interfaz con el usuario de Robbie CX30 tena menes muy grandes sin una obvia
organizacin interna. Esto crea una gran carga al operador en trminos de memoria y
tambin en trminos de tiempos de bsqueda, el tiempo que le lleva al operador ubicar una
opcin determinada de un men.
Muchas pantallas de dilogo requeran que el usuario ingresara con el teclado nmeros de
partes, nombres de archivos, y otra informacin. El sistema podra haberse diseado
facilmente de forma de mostrarle al usuario estos nmeros de parte, etc., sin necesitar que el
usuario recordara estas cosas de su propia memoria. Esto incrementaba la carga sobre la
memoria del usuario.
Para finalizar, y esto es realmente imperdonable, increble como puede parecer, no haba
ningna instalacin de ayuda en lnea o sensible al contexto! Si bien he ido a los cursos de
entrenamiento ofrecidos por Silicon Techtronics, muchas veces me encontr navegando por
los manuales de referencia para poder encontrar la respuesta a an las ms bsicas preguntas,
tales como:Qu significa esta opcin de men? Qu pasa si selecciono esta opcin?
5.
Pgina 20 de 37
Las fotos policiales de la escena del accidente no son nada agradables de ver. La consola del
operador estaba salpicada con bastante cantidad de sangre. No obstante, la calidad de las fotos
es excepcional y utilizando tcnicas de ampliacin pude descubrir los siguientes factores de
importancia sobre el momento en que fue decapitado Bart Matthews:
1.
El teclado IBM contiene un tablero numrico que puede operar de dos modos. Cuando la luz
NUM LOCK est encendida, esa parte se comporta como una calculadora. Del otro modo, las
teclas pueden usarse para mover el cursor en la pantalla.
2.
Las huellas ensangrentadas indican que Bart Matthews estaba usando el tablero numrico en
el momento en que fue golpeado y muerto.
3.
Esto nos dice la situacin de error vigente en el momento en que ocurri la tragedia. El
mensaje de error deca ROBOT DYNAMICS INTEGRITY ERROR-452
4.
Haba un manual de referencia que estaba apoyado abierto sobre el rea de
lectura/escritura de la estacin de trabajo
Uno de los cuatro volmenes del manual de referencia estaba abierto en la pgina del ndice
que contena el tem ERRORES/MENSAJES.
5.
Pgina 21 de 37
10:24:45 El robot gira del bao de cido y comienza a arrastrar la consola del operador, con
sus brazos dentados batindose con gran amplitud. Nadie esperaba que un operador tuviera
que huir de un robot descontrolado, as que Bart Matthews queda atrapado en su rea de
trabajo por el robot que avanza. Ms o menos para este momento es que Bart Matthews saca
el manual de referencia y empieza a buscar el error ERROR DE INTEGRIDAD DE DINMICA
DEL ROBOT - 45 en el ndice. Ubica con xito una referencia a mensajes de error en el ndice.
10:25:00 El robot ingresa al rea del operador. Bart Matthews abandona la bsqueda del
procedimiento del operador ante un error de integridad de dinmica del robot. En su lugar,
intenta una vez ms ingresar la secuencia de cancelacin de emergencia desde el teclado
numrico, momento en que es golpeado.
6.
Resumen y conclusiones
Si bien el mdulo de software escrito por Randy Samuels caus en verdad que el robot Robbie
CX30 oscilara fuera de control y atacara a su operador humano, un buen diseo de la
interfaz hubiera permitido al operador terminar con el comportamiento errtico del robot. En
base al anlisis de la interfaz del usuario del robot llevado a cabo utilizando las ocho reglas de
oro de Shneiderman, el experto en diseo de interfaces ha arribado a la conclusin de que el
diseador de la interfaz y no el programador fue la parte ms culpable en este desafortunado
evento.
7.
Referencias
1.
Gritty, Horace (1990). The Only User Interface Book Youll Ever Need. Vanity Press,
Oshkosh, WI, 212 pag. [El nico libro sobre Interfaz del usuario que usted necesitar]
2.
Gritty, Horace (1992). What We Can learn from the Killer Robot [Lo que podemos
aprender del robot asesino], charla dada en el Simposio Internacional de la Universidad
de Silicon Valley sobre Seguridad de Robots e Interfaces con el Usuario, Marzo de 1991.
Tambin por aparecer en las Notas de Alumnos de la Universidad de Silicon Valley.
3.
Gritty, Horace (se espera para 1993). CODEPENDENCY: How Computer Users Enable
Poor User Interfaces, Angst Press, New York [Cmo los usuarios de computadoras
permiten interfaces deficientes]
4.
Shneiderman, Ben (1987), Designing the User Interface, Addison-Wesley, Reading MA,
448 pag. [Diseo de Interfaces]
5.
6.
Foley, J. P., Wallace, V. L., y Chan, P. (1984): The Human Factors of Computer Graphics
Interaction Techniques [Los factores humanos de las tcnicas de interaccin de grficas
de computacin] IEEE COMPUTER GRAPHICS AND APPLICATIONS, 4(11) pag. 13-48.
Pgina 22 de 37
Pgina 23 de 37
Pgina 24 de 37
Ayudado por un grupo de graduados, el Profesor Silber descubri una discrepancia entre el
comportamiento real de la seccin del cdigo del programa (escrito por Randy Samuels) que
caus que el robot Robbie CX30 matara a su operador, y el comportamiento segn se lo
registr en la documentacin de pruebas de Silicon Techtronics. Este descubrimiento en
realidad fue hecho por Sandra Henderson, una estudiante graduada en ingeniera de software
que est completando su doctorado con el Profesor Silber. Entrevistamos a la Sra. Henderson
en uno de sus laboratorios de computacin para egresados en la Universidad de Silicon Valley.
Encontramos un problema en la prueba de la unidad, explic la Sra. Henderson. Ac estn
los resultados de la prueba, que nos dio el Sr. Waterson en Silicon Techtronics, que se supone
estn hechos para cdigo C [lenguaje de programacin] que Randy Samuels escribi y que
caus el incidente del robot asesino. Como puede ver, todo est claramente documentado y
organizado. Hay dos juegos de prueba: uno basado en una prueba de caja blanca y otro en
una prueba de caja negra. Basndonos en nuestros propios estndares para probar software,
estos juegos de prueba estn bien diseados, completos y rigurosos. La prueba de caja negra
implica ver la unidad de software (o sus componentes) como una caja negra que tiene
comportamientos predecibles de input y output. Si en el juego de prueba el componente
demuestra los comportamientos esperados para todos los inputs, entonces pasa la prueba. Los
juegos de prueba estn diseados para cubrir todos los comportamientos interesantes que
una unidad podra mostrar pero sin tener conocimiento alguno sobre la estructura o
naturaleza del cdigo en realidad. La prueba de caja blanca implica cubrir todos los pasos
posibles a travs de la unidad. As, la prueba de caja blanca se hace con vasto conocimiento de
la estructura de la unidad. En la prueba de caja blanca, el juego de prueba debe causar que
cada sentencia del programa se ejecute por lo menos una vez de modo que ninguna quede sin
ser ejecutada.
Sandra Henderson prosigui explicando el significado de la prueba de software. Ni la prueba
de caja blanca ni de caja negra prueban que un programa est correcto. No obstante, los
probadores de software, tales como los que se emplean en Silicon Techtronics, pueden
volverse bastante expertos en el diseo casos de prueba para descubrir nuevos bugs en el
software. La actitud apropiada es que una prueba es exitosa cuando se encuentra un bug.
Bsicamente, el probador le da un juego de especificaciones y hace lo mejor de s para
demostrar que el cdigo que est probando no satisface sus especificaciones, explic la Sra.
Henderson.
La Sra. Henderson luego mostr a este reporter los resultados de las pruebas que ella en
verdad obtuvo cuando corri el cdigo crtico del robot asesino usando los juegos de prueba
de la compaa, tanto para ensayo de caja blanca como de caja negra. En muchos casos, los
resultados registrados en los documentos de prueba de la compaa no fueron los mismos que
los generados por el verdadero cdigo del robot asesino.
Durante su entrevista de ayer con el SENTINEL-OBSERVER, el Profesor Silber discuti la
discrepancia. Ver, el software que en verdad fue entregado junto con el robot Robbie CX30
no fue el mismo que el que supuestamente fue probado, por lo menos de acuerdo con estos
documentos!. Hemos podido determinar que el verdadero cdigo asesino, tal como lo
llamamos, fue escrito despus de que se condujeron supuestamente las pruebas del software.
Esto sugiere varias posibilidades. Primero, el proceso de prueba de software, por lo menos
para esta parte crtica del software, fue falseado deliberadamente. Todos sabemos que hubo
una enorme presin para tener listo a este robot en una fecha determinada. Otra posibilidad
es que hubo una cierta dificultad en la versin de la gerencia en Silicon Techtronics, en
cuanto a que el cdigo correcto fue verdaderamente escrito, y probado con xito, pero en el
producto entregado se insert el cdigo equivocado.
Solicitamos al Profesor Silber que explicara que quera decir con versin de la gerencia. En
un proyecto dado, un componente dado de software puede tener varias versiones, versin 1,
versin 2, etc.
Pgina 25 de 37
Esto refleja la evolucin de ese componente a medida que avanza el proyecto. Se necesita tener
algn tipo de mecanismo para tener control de las versiones de los componentes de software
en un proyecto tan complejo como este. Tal vez el probador de software prob una versin
correcta del cdigo de dinmica del robot, pero en realidad se entreg una versin equivocada
del mismo. No obstante, esto trae a colacin una pregunta en cuanto a qu pas con el cdigo
correcto.
El Profesor Silber se reclin en su silln. Realmente esto es una gran tragedia. Si el cdigo
asesino hubiese sido pasado por el proceso de prueba de un modo honesto, el robot nunca
hubiese asesinado a Bart Matthews. Entonces, la pregunta es, qu pasaba en Silicon
Techtronics que no permiti una prueba honesta del cdigo crtico?
El SENTINEL-OBSERVER pregunt al Profesor Silber si estaba de acuerdo con el concepto de
que la interfaz del usuario fue la primordial culpable en este caso. No creo en el argumento
que esgrime mi colega, el Profesor Gritty, de que toda la culpabilidad en este caso pertenece al
diseador o diseadores de la interfaz. Concuerdo con ciertas cosas que dice, pero no con
todo. Debo preguntarme a m mismo si Silicon Techtronics estaba poniendo mucho nfasis en
la interfaz del usuario como la ltima lnea de defensa contra el desastre. Esto es, ellos saban
que haba un problema, pero pensaron que la interfaz del usuario podra permitirle al
operador manejarlo.
El SENTINEL-OBSERVER pregunt entonces al Profesor Silber sobre los cargos que se le hacan
en cuanto que nunca debera haber aceptado la designacin de Waterson para conducir una
investigacin objetiva del accidente. Las crticas sealan que la Universidad de Silicon Valley,
y en particular el Profesor Silber, tenan muchos intereses comunes con Silicon Techtronics, y
de ese modo no poda ser elegido para conducir una investigacin objetiva.
Pienso que mi informe habla por s mismo, replic el Profesor Silber, visiblemente molesto
por nuestra pregunta. Ya les he dicho a ustedes los periodistas una y otra vez que no se trat
de una investigacin gubernamental sino de una interna de la corporacin, de modo que creo
que Silicon Techtronics tena el derecho de elegir a quien se le ocurriera. Creo que yo les
resultaba una persona con integridad.
Ayer tarde, Sam Reynolds, el gerente de Proyecto del CX30 contrat a una abogada, Valerie
Thomas. La Sra. Thomas hizo estas declaraciones en favor de su cliente:
Mi cliente est escandalizado de que alguien de Silicon Techtronics haya podido engaar al
Profesor Silber en lo concerniente a las pruebas de software del robot Robbie CX30. El Sr.
Reynolds asegura que el software fue probado y que l y otros saban muy bien el hecho de
que haba algo que no funcionaba en el software de dinmica del robot. Sin embargo, el Sr.
Ray Johnson, el superior inmediato de mi cliente en Silicon Valley, decidi que el robot fuera
entregado a Cybernetics, Inc., basndose en la teora del Sr. Johnson: Nada es tan blanco
como la nieve.3
Conforme a esa teora, el software estaba casi libre de bugs y por ende poda ser liberado.
Segn el Sr. Johnson, el riesgo de falla era muy pequeo y el costo por demorar ms la entrega
del robot era muy alto. Segn mi cliente, el Sr. Johnson crey que las condiciones del medio
ambiente que podra llegar a disparar un comportamiento errtico y violento del robot eran
extremadamente improbables de ocurrir. An ms, el Sr. Johnson crey que el operador del
robot no podra estar en peligro debido a que la interfaz del usuario fue diseada de modo de
permitir al operador detener el robot fijo en sus guas en el caso de un movimiento del robot
que comprometiera la vida del operador.
El Sr. Johnson, Jefe de la Divisin Robtica de Silicon Techtronics, no pudo ser ubicado para
obtener sus comentarios. Randy Samuels ser juzgado el mes entrante en la Corte de Silicon
3Teora
Ivory Snow
Pgina 26 de 37
Valley. Cuando se lo contact por telfono, Samuels deriv todas las preguntas a su abogado,
Alex Allendale.
Allendale tena esto para decir con respecto a los descubrimientos del Profesor Silber:
Mi cliente remiti el software en cuestin del modo usual junto con la documentacin usual
y con la esperanza de que su cdigo fuera probado exhaustivamente. Desconoca hasta el
momento de que saliera a la luz el informe del Profesor Silber, que el cdigo involucrado en
esta terrible tragedia no haba sido probado adecuadamente o que los resultados de prueba
pudieran haber sido falsificados.
El Sr. Samuels nuevamente quiere expresar su gran pesar por este accidente. l, ms que
nadie, quiere que se haga justicia en este caso. El Sr. Samuels nuevamente extiende sus ms
sentidas condolencias a la Sra. Matthews y a sus hijos.
Pgina 27 de 37
Worthington explic que estaba poniendo a disposicin de la prensa las transcripciones del
correo electrnico porque quera que saliera a luz toda la verdad sobre Silicon Techtronics y
el incidente del robot asesino.
Los mensajes de E-mail entre empleados de Silicon Techtronics en verdad revelaron nuevas
facetas del caso. Un mensaje de Cindy Yardley al Jefe de Divisin Robtica, Ray Johnson,
indica que ella falsific a su pedido los resultados de las pruebas. Ac est el texto del
mensaje:
a:
de:
re:
Ray Johnson
Cindy Yardley
Software de Samuels
Termin de crear los resultados de las pruebas de software para ese software problemtico,
segn tu idea de usar una simulacin en vez del software propiamente dicho. Adjunto
encontrars el documento de prueba modificado, mostrando la simulacin exitosa.
Le deberamos decir a Randy sobre esto? Cindy
La respuesta de Johnson al mensaje de Yardley sugiere que l sospechaba que el correo
electrnico poda no ser seguro:
En respuesta a: Cindy Yardley
de: Ray Johnson
re: Software de Samuels
Saba que podra contar contigo. Estoy seguro de que tu dedicacin a Silicon Techtronics te
ser pagada con creces. Por favor, en el futuro us un medio de comunicacin ms seguro
cuando discutimos este tema. Te aseguro que el modo en que manejamos esto fue
completamente transparente, pero yo tengo mis enemigos ac mismo en la propia SiliTech.
Ray.
Estas comunicaciones fueron intercambiadas justo unos das antes que se enviara el robot
Robbie CX30 a Cybernetics Inc. Este hecho es importante porque las pruebas de software
falsificadas no fueron parte de un encubrimiento en el incidente del robot asesino. Estos
hechos parecen indicar que el propsito de falsificar las pruebas de software era asegurarse
de que el robot Robbie CX30 fuera entregado a Cybernetics, Inc. en la fecha que fue
negociada entre Silicon Techtronics y Cybernetics.
Las transcripciones del correo electrnico revelan que hubieron repetidos mensajes de Ray
Johnson a diferentes personas en el sentido de que la Divisin Robtica iba a ser cerrada
definitivamente si el proyecto Robbie CX30 no era completado en trmino. En uno de los
mensajes, diserta con su lder de proyecto, Sam Reynolds, acerca de la Teora Ivory Snow.
a:
de:
re:
Sam Reynolds
Ray Johnson
no seas un perfeccionista!
Sam:
T y yo hemos tenido nuestras diferencias, pero debo decirte que personalmente me caes bien.
Por favor entiende que todo lo que hago es con el propsito de SALVAGUARDAR TU TRABAJO
Y EL TRABAJO DE TODOS EN ESTA DIVISIN. Yo te veo a t y a toda la gente que trabajan
para m en la Divisin Robtica como mi familia.
Pgina 29 de 37
Waterson fue claro: quiere tener el proyecto del robot completado en trmino. Y punto.
Entonces, no tenemos otro recurso ms que el de Ivory Snow. Sabes lo que quiero decir con
eso. No tiene que ser perfecto. La interfaz del usuario es nuestro respaldo si esta versin del
software para el robot tiene algunas fallas. El operador del robot va a estar seguro porque
podr cancelar cualquier movimiento del robot en cualquier momento. Concuerdo contigo en
cuanto a que los requerimientos no funcionales son en algunas partes demasiado vagos. Lo
ideal sera que si estos no fueran tiempos de apuros, cuantificramos el tiempo que le llevara
al operador detener el robot en un caso de accidente.
Sin embargo no podemos renegociar esto ahora. Como tampoco tenemos tiempo para disear
requerimientos no funcionales nuevos y ms precisos.
No puedo enfatizar suficientemente de que estos son tiempos de apurarse. A Waterson no le
cuesta nada deshacerse de toda la Divisin Robtica. Sus amigos del Wall Street slo le van a
decir Felicitaciones!. Vers, para Waterson nosotros tan slo somos del montn.
Ray.
En este mensaje Ray Johnson parecera estar menos preocupado por la seguridad de
comunicarse por correo electrnico.
El SENTINEL-OBSERVER entrevist ayer por la tarde a Cindy Yardley en su propia casa. No se
pudieron contactar ni a Ray Johnson ni a Sam Reynolds.
La Srta. Yardley estaba notoriamente ofuscada porque sus mensajes por E-mail fueran dados a
conocer a la prensa. De alguna forma me siento aliviada. Sent una enorme culpa cuando ese
hombre fue muerto por un robot que yo ayud a producir. Una tremenda culpa.
El SENTINEL-OBSERVER pregunt a la Srta. Yardley si es que ella haba hecho una eleccin
tica al acceder a falsear los resultados de las pruebas de software. Respondi con gran
emocin. Nada, pero nada a lo largo de mi experiencia y background me prepar para algo
como lo que me pas. Estudi ciencias de la computacin en una universidad de gran nivel y
all me ensearon sobre pruebas de software, pero jams me dijeron que alguien con poder
sobre m me pedira generar una prueba falseada!
Cuando Johnson me pidi que lo hiciera, me llam a su oficina, como para mostrarme las
trampas del poder; ver, algn da me gustara estar en un puesto gerencial. Me sent en su
oficina y vino directamente y me dijo Quiero que falsifiques los resultados de las pruebas del
software de Samuels. No quiero que Reynolds se entere de nada de esto.
Yardley contuvo las lgrimas. Me asegur de que probablemente nadie vera jams los
resultados de las pruebas dado que el robot era perfectamente seguro. Era tan slo una
cuestin interna, un tema de prolijidad, en caso de que alguien de Cybernetics o de un puesto
alto dentro de la corporacin le diera curiosidad de ver los resultados de las pruebas. Le
pregunt si estaba seguro de que el robot era seguro y todo eso y me dijo Es seguro! La
interfaz del usuario es nuestra lnea de defensa. En alrededor de seis meses podemos enviar
una segunda versin del software del robot y para ese entonces este problema de Samuels
estar resuelto.
Yardley se reclin en su asiento como si lo que dijera a continuacin necesitara de un nfasis
especial. Entonces me dijo que si yo no falsificaba las pruebas, todos los de la Divisin
Robtica perderan sus trabajos. Sobre esa base decid falsificar las pruebas, trataba de
proteger mi trabajo y el de mis compaeros.
Pgina 30 de 37
Pgina 31 de 37
Pgina 32 de 37
se derrama sangre inocente en un pueblo, entonces los lderes de ese pueblo deben ir a los
lmites del mismo y realizar un acto de penitencia. Esto es adems de la justicia que se le
aplicar a la persona o personas que cometieron el asesinato.
SENTINEL-OBSERVER : Ese es un concepto interesante.
Yoder:
Y uno de verdad! Un pueblo, una ciudad, una corporacin son sistemas en que la
parte est ligada al todo y el todo a la parte.
SENTINEL-OBSERVER : Usted quiere decir que los lderes de Silicon Techtronics, tales como
Mike Waterson y Ray Johnson, deberan haber asumido la responsabilidad por este incidente
desde el vamos. Adems, tal vez otros individuos, como ser Randy Samuels y Cindy Yardley,
comparten una carga especial de responsabilidad.
Yoder:
S, responsabilidad, no culpabilidad. La culpabilidad es un concepto legal y la
culpabilidad o la inocencia de las partes involucradas, sean ya en lo criminal o lo civil, ser
decidida en la corte. Estimo que una persona es responsable por la muerte de Bart Matthews
si su accin ha ayudado a causar el incidente - es una cuestin de causalidad, independiente
de los juicios ticos y legales. Las cuestiones de responsabilidad podran serle de inters a los
ingenieros de software y gerentes, quienes tal vez querran analizar qu es lo que anduvo
mal, de modo de evitar que similares problemas ocurrieran en el futuro.
Mucho de lo que sali de los medios con respecto a este caso indica que Silicon Techtronics
era una organizacin enferma. Esa enfermedad cre el accidente. Quin cre la enfermedad?
La gerencia cre a esa enfermedad, pero tambin los empleados que no tomaron las decisiones
ticas correctas contribuyeron con la misma.
Tanto Randy Samuels como Cindy Yardley eran recin egresados. Se graduaron en ciencias de
la computacin y su primera experiencia en el mundo laboral fue en Silicon Techtronics. Uno
debera preguntarse si recibieron alguna enseanza sobre tica. Relacionado a esto est la
cuestin de si alguno de ellos tena con anterioridad experiencia en trabajos en grupo. En el
momento en que se los asign al desarrollo del robot asesino, ellos vieron la necesidad de ser
personas ticas? Vieron que el xito como profesionales requiere de un comportamiento
tico? Hay mucho ms para ser un cientfico en computacin o un ingeniero de software que
tan slo la habilidad y el conocimiento de la tcnica.
SENTINEL-OBSERVER : S con seguridad que ninguno de los dos tom cursos sobre tica o
tica de la computacin.
Yoder:
Lo sospechaba. Veamos a Randy Samuels. Basndome en lo que le en su peridico
y en otros lados, era bsicamente de los del tipo hacker. Amaba la computacin y la
programacin. Comenz a programar en los primeros aos de la secundaria y continu a lo
largo de toda la carrera universitaria. El punto importante es que Samuels an era un
hacker cuando entr en Silicon Techtronics y ellos le permitieron que l siguiera siendo as.
Estoy usando el trmino hacker de un modo un tanto peyorativo y tal vez esto no sea justo.
El punto que estoy tratando de remarcar es que Samuels nunca madur ms all de su angosto
enfoque como hacker. En Silicon Techtronics, Samuels an mantuvo esta actitud en lo que
haca a sus funciones de programador, la misma que tena cuando estaba en la secundaria. Su
percepcin de la vida y de sus responsabilidades no creci. l no madur. No hay evidencia de
que tratara de desarrollarse y convertirse en una persona tica.
SENTINEL-OBSERVER : Una dificultad, en lo que hace a ensear tica, es que en general los
estudiantes no les gusta que se les diga esto est bien y aquello est mal.
Yoder:
Los alumnos necesitan entender que el tocar temas de tica es parte de ser
computadores cientficos o ingenieros de software profesionales.
Una cosa que me ha fascinado acerca de la situacin de Silicon Techtronics es que a veces es
difcil ver los lmites entre lo legal, lo tcnico y lo tico. Los temas tcnicos involucran temas
Pgina 34 de 37
Yoder:
Robar software en el modo que lo hizo es tanto ilegal como no tico.
Pienso que el punto ms importante con Randy Samuels nunca fue discutido en los medios de
prensa. Honestamente dudo que Samuels tuviera el conocimiento necesario para su puesto.
Este tipo de conocimiento se lo llama conocimiento de la especialidad. Samuels tena
conocimiento de computacin y programacin, pero no tena un slido conocimiento de
fsica, en especial de la mecnica clsica. Su falta de conocimiento en el dominio de la
aplicacin fue una causa directa del horrible accidente. Si alguien con conocimientos de
matemticas, estadsticas y fsica hubiera programado al robot en lugar de Samuels,
probablemente hoy Bart Matthews estuviera vivo. No tengo dudas de ello. Samuels
malentendi la frmula fsica porque no entendi su significado e importancia en la
aplicacin en el robot. Puede ser que la gerencia sea en parte responsable por la situacin.
Puede que Samuels les haya dicho acerca de sus limitaciones y la gerencia habr dicho. Y
bueno, qu importa
Samuels tena dificultades en trabajar en equipo, hacer revisiones en conjunto, y programar
sin egosmo. Es posible que estuviera intentando esconder su falta de experiencia en el rea?
SENTINEL-OBSERVER : Cree que Ray Johnson actu ticamente?
Yoder:
Este tema del Ivory Snow! El problema con la teora del Ivory Snow es que es
tan solo eso, una teora. Si fuera ms que una teora, o sea una metodologa real para
mantener la probabilidad de la falla dentro de lmites estadsticamente determinados, como lo
que se llama ingeniera de software en sala limpia [cleanroom software engineering],
entonces habra menos culpabilidad en ese punto.
Basndome en la informacin que dispongo, la teora de Ivory Snow fue tan slo una
racionalizacin para sacarse de encima a software fallado y entregarlo en trmino al cliente.
Esta teora slo es vlida, tica y profesionalmente, si al cliente se le informa de los bugs de los
que se tiene conocimiento, o de impurezas, utilizando la jerga. En el caso de Silicon
Techtronics, la teora Ivory Snow funcion as: sabemos que no es puro, pero el cliente cree
que s lo es!
Desde luego, presionar a Cindy Yardley como lo hizo Ray Johnson tampoco es tico. El crea
en lo que le dijo a la Srta, Yardley, es decir, que el robot era seguro, o fue eso una mentira del
momento? Si el crea que el robot era seguro, entonces por qu cubrirse con pruebas falsas?
Si la interfaz con el usuario era tan importante como la ltima lnea de defensa, entonces por
qu evitar pruebas ms rigurosas de la interfaz?
SENTINEL-OBSERVER : Qu piensa de Mike Waterson en todo esto?
Yoder:
Si Johnson es el padre de la teora Ivory Snow, Waterson el es abuelo. Su exigencia
de que el robot estuviera completado para una fecha determinada o de lo contrario rodaran
cabezas, puede haber causado que Johnson formulara la teora Ivory Snow. Ver, es evidente
que Johnson pensaba que era imposible entregar a Cybernetics Inc. el robot CX 30 para una
fecha determinada, a menos que el software fuera con bugs.
En muchos sentidos pienso que Waterson actu sin tica e irresponsablemente. Pone a Sam
Reynolds a cargo del proyecto del robot, cuando an l, Reynolds, careca de experiencia con
robots e interfaces con el usuario modernas, Reynolds rechaz la idea de desarrollar un
prototipo, lo que podra haber permitido el desarrollo de una mejor interfaz.
Waterson cre una atmsfera opresiva entre sus empleados, que en s mismo es falto de tica.
No slo amenaz con despedir a todos los de la Divisin Robtica si el robot no se terminaba a
tiempo, sino que hurg en comunicaciones por correo electrnico privadas de toda la
corporacin, un derecho controvertido que algunas empresas alegan tener.
Mi creencia personal es que este tipo de investigacin es falto de tica. La naturaleza del Email es algo as como un hbrido de correspondencia comn y conversacin telefnica.
Monitorear o espiar la correspondencia ajena est considerado no tico, tal como lo es
interferir un telfono. Por cierto, estas actividades tambin son ilegales bajo la mayora de las
Pgina 36 de 37
circunstancias. O sea, creo que monitorear a los empleados del modo que lo hizo Waterson es
un abuso de poder.
SENTINEL-OBSERVER : Usted cree que en esto el fiscal tiene un caso?
Yoder:
SENTINEL-OBSERVER : S.
Yoder:
Lo dudo, a menos que ella tenga informacin que hasta ahora no se ha hecho
pblica. El asesinato no premeditado, a mi entender, implica un tipo de acto irresponsable y
negligente, que causa la muerte de un tercero. Se aplica esta descripcin a Samuels? Pienso
que la mejor apuesta de la fiscal es hacer hincapi en su falta de conocimiento en el rea de
aplicacin, si puede mostrarse que Samuels se involucr deliberadamente en un fraude.
La semana pasada le que el 79% de la gente est a favor de la absolucin. La gente es proclive
a acusar a la compaa y a sus gerentes. La otra noche, uno de los noticieros dijo, Samuels no
es un asesino, es un producto de lo que lo rodea.
SENTINEL-OBSERVER : Podra nuevamente decir su posicin sobre el tema de la
responsabilidad final en el caso del robot asesino?
Yoder:
En mi mente, el tema de la responsabilidad del individuo versus la responsabilidad
de la corporacin, es un tema muy importante. La corporacin cre un entorno en el que
podan ocurrir este tipo de accidentes. An as, los individuos, dentro de ese sistema, actuaron
sin tica e irresponsablemente, y fueron los que de hecho causaron el accidente. Una
compaa puede crear un entorno que saca a flote lo peor de sus empleados, pero cada
empleado tambin puede contribuir a empeorar ese ambiente corporativo. Este es un lazo
cerrado que se alimenta a s mismo, un sistema en el sentido clsico. Entonces, hay cierta
responsabilidad de la corporacin y cierta responsabilidad de los individuos en el caso del
robot asesino.
SENTINEL-OBSERVER : Muchas gracias Profesor Yoder.
Pgina 37 de 37