La ética en la ingeniería de software: Parte 1
Daños que podemos ocasionar al desarrollar sistemas computacionales
La historia reciente está llena de centenares de casos donde los sistemas computacionales han producido daños y perjuicios a usuarios finales y también a las empresas dueñas de dichos sistemas. La magnitud de los daños van desde pequeños inconvenientes, pérdidas económicas, problemas legales, violaciones de privacidad y fugas de datos y en algunos casos hasta la muerte de personas.
Según la intención original de los creadores del sistema, los daños producidos los podemos calificar en dos grandes categorías: Daños accidentales y daños intencionales.
Daños Accidentales
Los daños accidentales son problemas ocasionados a usuarios o stakeholders de un sistema por comportamientos o consecuencias no anticipadas de las reglas de negocios o de los algoritmos detrás de un sistema.
Veamos algunos casos históricos de este tipo de daños que nos pueden ayudar a entender la magnitud de los problemas que se pueden ocasionar al trabajar con sistemas.
Empecemos con el conocido Y2K; el bug del milenio que podía producir comportamientos inesperados en los sistemas durante el cambio de año de 1999 al año 2000.
Este defecto fue creado por la decisión de usar dos dígitos para representar el año en las fechas, una implementación que se eligió por las limitantes de memoria, capacidad de procesamiento y almacenamiento de los primeros computadores y que podría confundir a los computadores, que interpretarían la nueva fecha como el 1ero de enero de 1900 y no como el 1ero de enero del año 2000.
Hay quienes piensan que el posible impacto del Y2K se sobredimensionó y tambien están aquellos que consideran que realmente podía significar el fin de la civilización. En retrospectiva, parece que muchos sistemas se podían ir parcheando on-demand con poco impacto y a bajo costo pero en medio de un clima de incertidumbre bastante justificada por el desconocimiento se invirtieron centenares de millones de dólares y muchísimas horas/hombre.
Lo importante del caso Y2K es entender que nuestros programas tendrán una vida útil mucho mayor a la que podemos predecir y que las condiciones del mundo en el futuro pueden crear bugs y problemas que no somos capaces de anticipar cuando estamos creando especificaciones o escribiendo implementaciones. Veamos un ejemplo más “actual” con los ampliamente usados timestamps de UNIX que nos dan la “divertida” oportunidad de revivir el Y2K, ahora en la forma del Y2K38, cuando los enteros de 32 bits que usamos para representar las fechas hagan overflow en el año 2038.
El impacto del Y2K fue principalmente económico pero desafortunadamente hay errores con consecuencias mucho más graves, errores que incluso pueden ocasionar la muerte de personas. Éste es el caso de un terrible error en el software del Therac-25 una máquina de radioterapia para el tratamiento del cáncer. Los fallos en el software que controlaba el Therac-25 causaron que los pacientes recibieran una dósis de radiación potencialmente letal. La mayoría de los pacientes afectados por los fallos del Therac-25 sufrieron de envenenamiento por radiación y desafortunadamente tres personas murieron por estos accidentes.
La causa raíz del problema era un race-condition cuando un contador de un byte hacía overflow al mismo tiempo que el operador de la máquina ingresaba manualmente una instrucción específica, en ese momento se activaba el emisor de radiación del alta potencia pero no se posicionaba correctamente una placa deflectora que evitaba que el paciente recibiera una descarga de radiación mucho más alta que la que debía recibir.
Una serie de malas decisiones y malas prácticas de ingeniería hicieron posibles estos accidentes. En primer lugar, los modelos anteriores tenían mecanismos de seguridad en el hardware que impedían que el emisor de alta potencia se activara sin que la placa deflectora estuviera en posición, estas protecciones físicas fueron removidas en el nuevo modelo pero el equipo de programación reutilizó código de los modelos anteriores, donde no existía la necesidad de validar la posición del deflector. Tampoco se realizaron pruebas de integración exhaustivas que evaluaran adecuadamente la interacción entre el hardware y el software para detectar problemas, y el computador no tenía mecansimos para sincronizar el estado del hardware o validar el resultado de una operación luego de enviar una instrucción (Controladores de lazo abierto). Todas estas y muchas otras fallas en los procesos de ingeniería fueron responsables de heridas y muertes de pacientes y nos dan un ejemplo bastante extremo pero contundente para entender la responsabilidad que tenemos, no sólo individualmente sino a nivel de equipos y de organizaciones, sobre los efectos no anticipados de los sistemas que creamos.
En resumen, los daños accidentales los ocasionan principalmente: bugs, interacciones y comportamientos no esperados, fallos y agujeros de seguridad no detectados, discrepancias entre la especificación y la implementación de un algoritmo, módulo, sistema o servicio, fallas de comunicación entre los equipos responsables del desarrollo y procesos de ingeniería deficientes implementados por equipos que no desarrollan una visión integral del sistema que están creando o manipulando y que no ajustan sus prácticas a las condiciones y restricciones complejas del mundo.
Daños Intencionales
A diferencia de los daños accidentales, los daños intencionales los ocasionan sistemas cuyas reglas de negocio producen daños y perjuicios a propósito. Generalmente este tipo de daños son top-to-bottom, es decir, las empresas y otras organizaciones dueñas de sistemas deciden de forma consciente implementar reglas de negocio que de alguna manera perjudican a usuarios u otros stakeholders.
Para hablar de los daños intencionales al desarrollar software me parece que por el momento basta con revisar uno de los casos más controversiales y de mayor impacto de los últimos años, el llamado dieselgate o emissiongate, un escándalo que se hizo público en septiembre de 2015, ocasionado por que en Volkswagen modificaron un dispositivo de inyección para que detectara el momento exacto en que la Agencia de Protección Ambiental estaba inspeccionando las emisiones de gases de un auto para activar sólo en ese momento los mecanismos de control de emisiones de gases, engañando a los sistemas de medición y logrando que el auto pasara las inspecciones técnicas sin necesidad de alterar significativamente el funcionamiento del motor. La modificación de software fue realizada en varios de los modelos de autos diesel de Volkswagen fabricados entre 2009 y 2015.
El conflicto se dió por terminado luego de que la EPA (Agencia de Protección Ambiental de los EE.UU.) demandara a Volkswagen, al final la empresa se vió obligada a pagar miles de millones de dólares en indemnizaciones y costos de modificación o retiro del mercado de los autos afectados por la alteración ilegal.
Esta acción de Volkswagen tuvo obvias consecuencias en la salud de muchas personas y sobre el medio ambiente; a nosotros como profesionales de la industria del software en este caso específico nos interesan en particular dos temas: En primer lugar la obvia responsabilidad que tuvieron los ingenieros electrónicos y de software involucrados en las modificaciones ilegales al dispositivo electrónico que engañaban a las pruebas de emisión, y en segundo lugar, la respuesta de la directiva de Volkswagen que en varias de sus comunicaciones se enfocó en decir que un "pequeño grupo de personas" (En palabras literales de uno de sus ejecutivos) había sido el responsable del incidente; es decir, para librarse de la responsabilidad general como organizacion buscaron culpar exclusivamente a los equipos de ingeniería más cercanos al funcionamiento del dispositivo de inyección.
Sobre el primer punto, sin entrar en la controversia sobre si la decisión vino desde más arriba para que los ingenieros la implementaran o si fue una iniciativa llevada a cabo enteramente por los equipos de ingeniería, lo que queda claro es que quienes finalmente decidieron implementar las modificaciones ilegales al dispositivo fueron los ingenieros de Volkswagen, y eso los hace directamente responsables de aumentar las emisiones de gases de nitrógeno y carbono a niveles nocivos para la salud de cientos de miles de personas y nocivos tambien para el medio ambiente (Se estima que incluso se producirán muertes prematuras por los daños a la salud), y en el caso de que hayan actuado por iniciativa propia, también los hace directamente responsables de un escándalo que afectó la imagen, marca, reputación, ventas y finanzas de la compañía.
Al encontrarnos ante la posibilidad, obligación o necesidad de implementar funcionalidades que vayan en contra de las leyes o que tendrán consecuencias negativas evidentes para los usuarios y/o para la compañía para la que trabajamos debemos siempre cuestionarnos si lo que estamos haciendo es lo correcto y según la severidad de las consecuencias, cuestionar y proponer alternativas diferentes, directamente oponernos a implementar la funcionalidad o si el caso lo ameritara y nuestra situación lo permitiera, reportarlo a las autoridades competentes para que actúen como corresponde según la ley.
Por supuesto, en el papel todo es fácil, en la vida real, no tanto; cuando hay hijos y otros familiares que dependen de nuestro trabajo, cuando hay hipotecas que pagar o cuando el empleador de alguna manera puede afectar nuestra carrera y reputación como profesionales, la decisión real es muchísimo más difícil de tomar. En la última sección de esta serie hablaré sobre asociaciones gremiales existentes y otras que deberían crearse, que tienen un doble rol, definir un código de ética y prácticas ajustadas a las realidades de nuestra profesión y luego ser un respaldo legal y gremial para esos profesionales que tomen decisiones éticas que pueden afectar negativamente su vida personal y profesional.
El segundo tema del escándalo en el que debemos enfocarnos es en la forma tan fácil en la que la alta gerencia de la compañía hizo recaer la culpa total sobre el equipo de ingeniería, obviando que muchas más personas, equipos y gerentes de la compañía, por acción, por coerción o por omisión tambien tienen una cuota de responsabilidad.
Somos profesionales de una industria muy nueva, en transformación constante y que como comentaba en el artículo anterior, literalmente se encarga de hacer que la sociedad fuincione. Una industria que la mayoría de las personas no entiende muy bien, no comprenden nuestra forma de trabajar, el tipo de trabajo que hacemos, las tecnologías involucradas y muchas veces nisiquiera entienden las capacidades y limitaciones de nuestro trabajo, por ese motivo, para el público general, para periodistas, legisladores, jueces y hasta para la directiva de las empresas es bastante difícil tener una visión integral que les permita entender los eventos, diferenciar causas de consecuencias y muchos otros problemas de criterio que pueden llevarnos a ser chivos expiatorios fáciles sobre quienes lanzar la culpa de desastres de todas las magnitudes.
Debemos auto regularnos como industria, demostrarle a la sociedad que comprendemos las posibles consecuencias de nuestro trabajo, que estamos conscientes del importante rol que tenemos dentro del buen y el mal funcionamiento del mundo y lo más importante, debemos trabajar bajo estándares y reglas estrictos que garanticen que no vamos a ocasionar daños a usuarios, empresas, organizaciones o naciones de manera consciente e intencional. Volviendo a citar la charla de Bob Martin que enlacé en el post anterior, si no nos regulamos nosotros mismos el estado, desde su desconocimiento y miopía respecto a nuestra industria, intentará implementar las regulaciones, luego del próximo gran desastre que ocasionemos.
Continúa leyendo la segunda parte de esta serie de artículos haciendo click aquí.
Índice de Artículos
- La ética en la ingeniería de software.
- Daños accidentales y daños intentionales ocasionado por los computadores.
- Big Brother is watching, privacidad en la era digital.
- HAL 9000 o como aprendí a dejar de preocuparme y amar a la inteligencia artificial general.
- Red, Green, Refactor: La mejora continua de las organizaciones, equipos y profesionales como mecanismo de prevención.
- La profesionalización en la industria del software.
