211service.com
Por qué el software es tan malo
Es uno de los chistes más antiguos de Internet, que se reenvía sin cesar de un buzón de correo electrónico a otro. Un magnate del software, generalmente Bill Gates, pero a veces otro, pronuncia un discurso. Si la industria del automóvil se hubiera desarrollado como la industria del software, proclama el magnate, todos estaríamos conduciendo autos de $ 25 que recorren 1,000 millas por galón. A lo que un ejecutivo de automóviles responde: Sí, y si los automóviles fueran como un software, se estrellarían dos veces al día sin ningún motivo, y cuando llamaras al servicio técnico, te decían que reinstalaras el motor.
La broma resume uno de los grandes acertijos de la tecnología contemporánea. En un tiempo sorprendentemente corto, el software se ha vuelto fundamental para casi todos los aspectos de la vida moderna. Desde las bóvedas de los bancos hasta los semáforos de las ciudades, desde las redes telefónicas hasta los reproductores de DVD, desde las bolsas de aire de los automóviles hasta los sistemas de control del tráfico aéreo, el mundo que nos rodea está regulado por códigos. Sin embargo, gran parte del software simplemente no funciona de manera confiable: pregúntele a cualquiera que haya visto la pantalla de una computadora en azul, eliminando horas de esfuerzo. Con demasiada frecuencia, dicen los ingenieros de software, el código está inflado, es feo, ineficiente y está mal diseñado; incluso cuando los programas funcionan correctamente, los usuarios los encuentran demasiado difíciles de entender. Gimiendo bajo el peso de manuales parecidos a ladrillos, los estantes de las librerías de todo el país dan testimonio de la perdurable disfuncionalidad del software.
El software es simplemente terrible hoy en día, dice Watts S. Humphrey, miembro del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon que ha escrito varios libros conocidos sobre la calidad del software. Y está empeorando todo el tiempo. Un buen software, en opinión de Humphrey, es utilizable, confiable, libre de defectos, rentable y fácil de mantener. Y el software ahora no es ninguna de esas cosas. No puede sacar algo de la caja y saber que va a funcionar. A lo largo de los años, en opinión de Edsger W. Dijkstra, un científico informático emérito de la Universidad de Texas en Austin, el usuario promedio de computadoras ha recibido tan mal servicio que espera que su sistema se bloquee todo el tiempo, y somos testigos de un impacto masivo distribución mundial de software plagado de errores por lo que deberíamos estar profundamente avergonzados.
Jim McCarthy es más generoso. El fundador, con su esposa Michele, de una compañía de capacitación en calidad de software en Woodinville, WA, McCarthy cree que la mayoría de los productos de software tienen las características necesarias para que valga la pena comprarlos, usarlos y adoptarlos. Pero, admite, solo la extrema utilidad del software nos permite tolerar sus enormes deficiencias. McCarthy a veces comienza las charlas en su escuela con una presentación de PowerPoint. La primera diapositiva dice: La mayoría del software apesta.
Es difícil enfatizar demasiado la singularidad de los problemas del software. Cuando los ingenieros automotrices analizan los automóviles en el mercado, no dicen que los vehículos de hoy no sean mejores que hace diez o quince años. Lo mismo ocurre con los ingenieros aeronáuticos: nadie afirma que Boeing o Airbus fabriquen aviones pésimos. Los ingenieros eléctricos tampoco se quejan de que los chips y los circuitos no estén mejorando. Como sugirió el historiador de la ingeniería Henry Petroski en su libro de 1992 La evolución de las cosas útiles , el refinamiento continuo es la regla habitual en tecnología. Los ingenieros notan constantemente las deficiencias en sus diseños y las arreglan poco a poco, un proceso que Petroski describió irónicamente como la forma sigue al fracaso. Como resultado, los productos mejoran gradualmente.
El software, por desgracia, parece diferente. Uno esperaría que un programa de 45 millones de líneas como Windows XP, el sistema operativo más nuevo de Microsoft, tuviera algunos errores. Y la ingeniería de software es una disciplina más nueva que la ingeniería mecánica o eléctrica; los primeros programas reales se crearon hace solo 50 años. Pero lo que es sorprendente (de hecho, asombroso) es que muchos ingenieros de software creen que la calidad del software no está mejorando. En todo caso, dicen, está empeorando. Es como si los autos que Detroit produjo en 2002 fueran menos confiables que los construidos en 1982.
A medida que el software se vuelve cada vez más importante, el impacto potencial del código incorrecto aumentará para igualar, en opinión de Peter G. Neumann, científico informático de SRI International, un centro privado de I + D en Menlo Park, CA. Solo en los últimos 15 años, los defectos del software arruinaron el lanzamiento de un satélite europeo, retrasaron la apertura del costoso aeropuerto de Denver durante un año, destruyeron una misión de la NASA a Marte, mataron a cuatro marines en un accidente de helicóptero e indujeron a un barco de la Marina de los EE. UU. A destruir un avión civil y cerró los sistemas de ambulancias en Londres, lo que provocó hasta 30 muertes. Y debido a nuestra creciente dependencia de la Red, dice Neumann, estamos mucho peor que hace cinco años. Los riesgos son peores y las defensas no tan buenas. Estamos retrocediendo, y eso da miedo.
Algunas empresas de software están respondiendo a estas críticas renovando sus procedimientos; Microsoft, afectado por las acusaciones de que sus productos tienen errores, está liderando públicamente el camino. Sin embargo, los problemas con la calidad del software han perdurado durante tanto tiempo y parecen tan incrustados en la cultura del software que algunos programadores están empezando a pensar en lo impensable. Para su propio asombro, estas personas se han preguntado si el verdadero problema con el software es que no hay suficientes abogados involucrados.
Falta de lógica
Microsoft lanzó Windows XP el 25 de octubre de 2001. Ese mismo día, en lo que puede ser un récord, la compañía publicó 18 megabytes de parches en su sitio web: correcciones de errores, actualizaciones de compatibilidad y mejoras. Dos parches arreglaron importantes agujeros de seguridad. O mejor dicho, uno de ellos lo hizo; el otro parche no funcionó. Microsoft recomendó (y aún aconseja) a los usuarios que realicen una copia de seguridad de los archivos críticos antes de instalar los parches. Sin embargo, los compradores de la versión doméstica de Windows XP descubrieron que el sistema no ofrecía ninguna forma de restaurar estos archivos de respaldo si las cosas salían mal. Como explica suavemente la base de conocimientos en línea de Microsoft, los disquetes de copia de seguridad especiales creados por Windows XP Home no funcionan con Windows XP Home.
Tales deslices, dicen los críticos, son simplemente lapsos superficiales, signos de que los desarrolladores del software fueron demasiado apresurados o descuidados para corregir defectos obvios. Los verdaderos problemas radican en el diseño básico del software, según R. A. Downes de Radsoft, una empresa de consultoría de software. O mejor dicho, es ausencia de diseño. El popular software de programación Visual Studio de Microsoft es un ejemplo, según la forma de pensar de Downes. Downes ha descubierto que simplemente colocando el cursor sobre la ventana de Visual Studio, bombardea de forma invisible la unidad central de procesamiento con miles de mensajes innecesarios, a pesar de que el programa no está haciendo nada. Es cataclísmico, es un caos total, se queja.
El problema, en opinión de Dan Wallach, un científico informático de la Universidad de Rice, no es la agitación inútil del procesador; después de todo, señala, la potencia de procesamiento es barata. El software de Microsoft tampoco es especialmente defectuoso; los críticos a menudo emplean los productos de la empresa como ejemplos más porque son familiares que porque son inusualmente malos. En cambio, en opinión de Wallach, la confusión floreciente y zumbante en Visual Studio y tantos otros programas traiciona cómo las técnicas para escribir software no han podido mantenerse al día con el aumento explosivo de su complejidad.
Los programadores escriben código en lenguajes como Java, C y C ++, que pueden ser leídos por seres humanos. Los programas especializados conocidos como compiladores transforman este código en cadenas de unos y ceros que utilizan las computadoras. Es importante destacar que los compiladores se niegan a compilar código con problemas obvios; en su lugar, escupen mensajes de error. Hasta la década de 1970, los compiladores se sentaban en grandes mainframes que a menudo se reservaban con días o semanas de anticipación. No queriendo que los errores causaran retrasos, los codificadores -que en los primeros días solían ser entrenados como matemáticos o físicos- se quedaban hasta tarde en sus oficinas revisando exhaustivamente su trabajo. Escribir software era muy parecido a escribir artículos científicos. El rigor, la documentación y la revisión por pares eran la costumbre.
Pero a medida que las computadoras se generalizaron, las actitudes cambiaron. En lugar de planificar meticulosamente el código, los programadores permanecían despiertos en sesiones de piratería con cafeína durante toda la noche, obteniendo resultados constantemente del compilador. Una y otra vez, el compilador devolvía mensajes de error; los programadores corregirían los errores uno por uno hasta que el software se compilara correctamente. La actitud actual es que se puede escribir cualquier fragmento de código descuidado y el compilador ejecutará diagnósticos, dice Neumann de SRI. Si no arroja un mensaje de error, debe hacerlo correctamente, ¿verdad?
Sin embargo, a medida que los programas crecían en tamaño y complejidad, los límites de este código y enfoque de corrección se hicieron evidentes. En promedio, los codificadores profesionales cometen de 100 a 150 errores en cada mil líneas de código que escriben, según un estudio de varios años de 13.000 programas realizado por Humphrey de Carnegie Mellon. Utilizando las cifras de Humphrey, el sistema operativo empresarial Windows NT 4, con sus 16 millones de líneas de código, se habría escrito con unos dos millones de errores. La mayoría habrían sido demasiado pequeños para tener algún efecto, pero algunos, muchos miles, habrían causado serios problemas.
Naturalmente, Microsoft probó exhaustivamente NT 4 antes del lanzamiento, pero en casi cualquier fase de las pruebas encontrará menos de la mitad de los defectos, dice Humphrey. Si Microsoft hubiera pasado por cuatro rondas de pruebas, un procedimiento costoso y que requiere mucho tiempo, la compañía habría encontrado como máximo 15 de los 16 errores. Eso te dejará con algo así como cinco defectos por cada mil líneas de código, dice Humphrey. Lo cual es muy bajo, pero el software aún tendría hasta 80.000 errores.
Los ingenieros de software saben que su código a menudo está plagado de lagunas y llevan mucho tiempo buscando nuevas tecnologías para prevenirlas. Para gestionar proyectos cada vez más dilatados como Windows, por ejemplo, han desarrollado una variedad de técnicas, de las cuales quizás la más conocida sea el diseño basado en componentes. Así como las casas se construyen con dos por cuatro y accesorios eléctricos estandarizados, los programas basados en componentes se construyen a partir de elementos modulares e intercambiables: un ejemplo es la barra de menú casi idéntica en la parte superior de cada programa de Windows o Macintosh. Dichos componentes estandarizados, según Wallach, no solo son buenas prácticas de ingeniería, son la única forma en que puede hacer que algo del tamaño de Microsoft Office funcione. Microsoft, dice, fue uno de los primeros y agresivos promotores de este enfoque: es la mejor decisión de ingeniería que jamás hayan tomado.
Desafortunadamente, dicen los críticos, los componentes a menudo están pegados sin un plan central real, como si los contratistas intentaran construir grandes estructuras sin planos. Increíblemente, dice Humphrey, el diseño de grandes proyectos de software a veces no es más que un par de burbujas en el reverso de un sobre. Peor aún, por razones de marketing, las empresas conectan tantas funciones como sea posible en el nuevo software, contrarrestando los beneficios de la construcción modular. El ejemplo más extendido es el propio Windows, que Bill Gates testificó en una sesión de abril de la prueba antimonopolio de Microsoft simplemente no funcionaría si los clientes eliminaran componentes individuales como navegadores, administradores de archivos o programas de correo electrónico. Esa es una afirmación increíble, dice Neumann. Significa que no hay estructura o arquitectura o rima o razón en la forma en que han construido esos sistemas, aparte de hacerlos tan agrupados como sea posible, de modo que si quita alguna parte, todo fallará.
El diseño inadecuado de los productos finales, argumentan los críticos, refleja una planificación inadecuada en el proceso de creación. Según un estudio realizado por Standish Group, una empresa de consultoría en West Yarmouth, MA, los proyectos de software comercial de EE. UU. Están tan mal planificados y administrados que en 2000 casi una cuarta parte se cancelaron por completo, sin generar un producto final. Los proyectos cancelados cuestan a las empresas $ 67 mil millones; los excesos en otros proyectos acumularon otros $ 21 mil millones. Pero debido a que el código y la corrección conducen a rondas de pruebas tan extensas y costosas, incluso los proyectos exitosos pueden ser tremendamente ineficientes. Increíblemente, los proyectos de software a menudo dedican 80 por ciento de sus presupuestos para reparar fallas que ellos mismos produjeron, una cifra que no incluye el proceso aún más costoso de brindar soporte al producto y desarrollar parches para los problemas encontrados después del lanzamiento.
Las pruebas del sistema continúan durante casi la mitad del proceso, dice Humphrey. E incluso cuando finalmente lo hacen funcionar, todavía no hay diseño. En consecuencia, el software no se puede actualizar ni mejorar con la garantía de que las actualizaciones o mejoras no introducirán fallas importantes. Así es como se diseña y construye el software en todas partes; es así en las naves espaciales, por el amor de Dios.
¿Es el software un caso especial?
Los riesgos potenciales del software defectuoso quedaron sombríos entre 1985 y 1987, cuando una máquina de radioterapia controlada por computadora fabricada por la Energía Atómica de Canadá, respaldada por el gobierno, produjo una sobredosis masiva de pacientes en los Estados Unidos y Canadá, matando al menos a tres. En un examen exhaustivo, Nancy Leveson, ahora científica informática del MIT, atribuyó gran parte de la culpa a las prácticas inadecuadas de ingeniería de software del fabricante. Debido a que el programa utilizado para establecer la intensidad de la radiación no se diseñó o probó con cuidado, los simples errores de escritura desencadenaron explosiones letales.
A pesar de esta trágica experiencia, máquinas similares que ejecutaban software fabricado por Multidata Systems International, de St. Louis, causaron una sobredosis masiva de pacientes en Panamá en 2000 y 2001, lo que provocó ocho muertes más. Un equipo de la Agencia Internacional de Energía Atómica atribuyó las muertes al ingreso de datos de una manera que los programadores no habían anticipado. Como señala Leveson, los errores simples de entrada de datos no deberían tener consecuencias letales. Por lo tanto, esta falla también puede deberse a un software inadecuado.
Los expertos en programación tienden a estar de acuerdo en que tales desastres son terriblemente comunes. Considere el Mars Climate Orbiter y el Polar Lander, ambos destruidos en 1999 por errores de codificación familiares y fáciles de evitar. Pero algunos argumentan que el software simplemente no se puede juzgar, medir y mejorar de la misma manera que otros productos de ingeniería. Es solo un hecho que hay cosas que otros ingenieros pueden hacer y que nosotros no podemos hacer, dice Shari Lawrence Pfleeger, investigadora principal del grupo de expertos Rand en Washington, DC, y autora del volumen de 2001 Ingeniería de software: teoría y práctica . Si un puente sobrevive a un peso de 500 kilogramos y a un peso de 50.000 kilogramos, señala Pfleeger, los ingenieros pueden asumir que soportará todos los valores intermedios. Con el software, dice, no puedo hacer esa suposición, no puedo interpolar.
Además, los fabricantes de software trabajan bajo demandas extraordinarias. Ford y General Motors han estado fabricando el mismo producto, una caja de cuatro ruedas con un motor de combustión interna, durante décadas. En consecuencia, dice Charles H. Connell, ex ingeniero principal de Lotus Development (ahora parte de IBM), han podido mejorar sus productos de forma incremental. Pero a las empresas de software se les pide constantemente que creen productos: navegadores web a principios de la década de 1990, nuevas interfaces para teléfonos móviles en la actualidad, como nunca antes se había visto. Es como si un fabricante de automóviles dijera: Este año vamos a hacer un cohete en lugar de un automóvil, dice Connell. Por supuesto que tendrán problemas.
El dilema clásico en el software es que la gente continuamente quiere más y más cosas, dice Nathan Myhrvold, ex director de tecnología de Microsoft. Desafortunadamente, señala, la demanda constante de novedades significa que el software siempre está en la fase de vanguardia, cuando los productos son intrínsecamente menos confiables. En 1983, dice, Microsoft Word tenía solo 27.000 líneas de código. El problema es que no sirvió de mucho, lo que los clientes de hoy no aceptarían. Si Microsoft no hubiera seguido mejorando Word con nuevas funciones, el producto ya no existiría.
Los usuarios son tremendamente inconscientes de sí mismos, agrega Myhrvold. En Microsoft, dice, los clientes corporativos a menudo exigían que la empresa agregara simultáneamente nuevas funciones y dejara de agregar nuevas funciones. Literalmente, lo he escuchado en un solo suspiro, una sola oración. No estamos seguros de por qué deberíamos actualizar a esta nueva versión (tiene todas estas cosas que no queremos) y ¿cuándo vas a poner estas tres cosas? 'Y tú dices, ¿Qué?' Resumen sardónico de Myhrvold: Software apesta porque los usuarios lo exigen.
Estándares más altos
En enero, Bill Gates hizo un llamado a los empleados de Microsoft para que hicieran de la informática confiable y segura su máxima prioridad. En lo que la compañía anunció como una de sus iniciativas más importantes en años, Gates exigió que Microsoft redujera drásticamente la cantidad de defectos en sus productos. Un mes después, la empresa dio el paso sin precedentes de suspender toda la escritura de código nuevo durante casi dos meses. En cambio, reunió a los programadores, mil a la vez, para sesiones de capacitación masivas sobre confiabilidad y seguridad. Usando pantallas gigantes en un auditorio gigante, los ejecutivos de la compañía mostraron fragmentos vergonzosos de código defectuoso producido por la audiencia.
La iniciativa de Gates aparentemente se inspiró en la explosión de críticas que se apoderaron de Microsoft en julio de 2001 cuando un desbordamiento del búfer -un tipo de error familiar desde hace mucho tiempo- en su software de servidor web de Internet Information Services permitió que el gusano Code Red victimizara a miles de sus clientes corporativos. (En un desbordamiento del búfer, un programa recibe más datos de los esperados, como si uno llenara el espacio de un código postal con un número de 50 dígitos. En una computadora, la información adicional se derramará en partes adyacentes de la memoria, corrompiendo o sobrescribiendo los datos allí, a menos que estén cuidadosamente bloqueados). Dos meses después, el gusano Nimda aprovechó otras fallas en el software para atacar miles de máquinas más.
Golpeados por tales experiencias, los desarrolladores de software están cada vez más atentos a la calidad. Incluso cuando Gates estaba reuniendo a sus tropas, los think tanks como el Kestrel Institute, de Palo Alto, CA, estaban desarrollando kits de herramientas de programación correctos por construcción que casi obligan a los codificadores a escribir programas confiables ( consulte Primeros auxilios para códigos defectuosos ). En la propia Microsoft, según Amitabh Srivastava, director del Centro de Investigación de Productividad del Programador de la empresa, los codificadores están trabajando con nuevos lenguajes de nivel superior como C # que no permiten ciertos errores. Y en mayo, Microsoft cofundó el Consorcio de Computación Sostenible de $ 30 millones, con sede en Carnegie Mellon, con la NASA y otras 16 empresas para promover formas estandarizadas de medir y mejorar la confiabilidad del software. Los esfuerzos de control de calidad pueden dar buenos resultados: al ayudar a Lockheed Martin a renovar el software en su avión C130J, Praxis Critical Systems, de Bath, Inglaterra, utilizó tales métodos para reducir los costos de desarrollo en un 80 por ciento mientras producía software que pasó los estrictos exámenes de la Administración Federal de Aviación con muy pocos errores.