Escribimos software pésimo... ¡y con bugs!

Leonardo Herrera
Creado: 12/2/2003
Última Actualización: 21/9/2004

Hace siete años atrás, Dave Winer escribió un muy interesante artículo titulado "We make shitty software... with bugs!". Si entienden inglés, léanlo, es bastante divertido y a pesar de que está escrito de manera ligera, es un clásico. El artículo (de 1995) además habla sobre Netscape y el "recién salido" Internet Explorer. Pero es sobre el tema tocado por la primera parte del artículo sobre la que me gustaría decir algunas cosas.

No importan todos tus esfuerzos, el software que produces es pésimo

Esta es una realidad a la que todos los productores de software debemos atenernos. Es imposible desde el punto de vista comercial y técnico crear software perfecto. Antes de que me lancen tomates, sí existe software que es cercano a la perfección: el firmware de algunos componentes críticos, sistemas de misión crítica -el programa controlador de un Boeing, por ejemplo-, etc. Usualmente, estas piezas de software no son tan complejos como el software que uno usa diariamente. No, no estoy hablando de más; un módulo de control tiene un número definido de funciones, coexiste con un entorno de hardware controlado y además está afinado. Sin contar que los procesos que rigen el desarrollo de este tipo de software son más grandes que el mismo software producido: no hay una sóla línea de código que no esté auditada.Y, sin embargo, tiene más fallas que Office.

Sí, lo que leen. El software usado para controlar que dos aviones no choquen en el aire tiene fallas, y muchas.

Para ser justos, el software que se usaba en USA fue escrito en los '70, y era ejecutado en aparatos con tubos de vacío ( IBM 9020e, fabricado en los '60). Para ahora ya lo deben haber reemplazado con nuevos sistemas, hace uno o dos años estaban en las fases finales de deployment despues de una década de desarrollo.

¿Porqué el software falla? La única razón es procesos de diseño, implementación y pruebas defectuosos. No obstante, aún no existe un proceso infalible para ninguno de estos ítems, y además, es costoso. Un dato: cada línea de código en el software de control de un transbordador espacial cuesta 1000 dólares. Y eso es el costo para el contratista, en este caso, una empresa llamada Loral.

Ahora, para el software comercial o de uso no crítico, el costo es infinitamente inferior, por supuesto, pero esto responde a algo sencillo: ¿pagaría uno 5000 dólares por una planilla de cálculo?

Yo no.

Asumir que el software propio es malo

Ah, la parte difícil. Para un desarrollador apasionado por su trabajo, cada pieza de software es como un hijo, y nos duele ver que un usuario diga tu software apesta. Así que lo mejor es asumir que nuestro software apesta, aceptarlo y quererlo. Esto implica seguir trabajando duro, corregir errores, lanzar nuevas versiones con mejoras y arreglos.

Cada vez que un usuario reclama por nuestro software, debemos entender esto: el cliente tiene la razón. No, no es un slogan comercial: es la verdad. Si el software no hace lo que se espera de él, implica que es malo. Pero no hay que echarse a morir: uno debe solucionar el problema, hacer pruebas, y lanzar una nueva versión. Sí, hacemos mal software, pero la próxima vez estará un poco mejor. Y mejor la siguiente.

La clave está en interiorizar, alegremente, que la perfección es imposible, pero perseguirla es posible y la única manera de mejorar. Un poco de filosofía aplicada al software no hace mal.

Tomar medidas para minimizar errores

Parece sencillo, pero no lo es. La forma de facto en este momento es llamada "unit testing". Básicamente, consiste que cada vez que uno crea una nueva funcionalidad en algún programa, debe crear además otro programa que invoque estas funcionalidades contra un set de respuestas conocidas de antemano, e incorporar el programa de prueba a una línea de producción, conocidas como automated testing. Esto tiene el efecto de que cada cosa que se haga cuesta más: ya no es sólo programar y crear un prototipo para probar, sino que cada pequeña funcionalidad debe funcionar perfectamente. Más código que escribir, pero a la larga, funciona.

Un ejemplo. Juanito Pérez escribe un módulo que contiene una función que debe contar las líneas de un archivo. La escribe, y luego crea un programa de pruebas, que llama a esa función con ciertas condiciones: por ejemplo, si llamo a esa función y le digo que abra un archivo que no existe, debe retornar un error; si se le indica a la función que abra un archivo con 0 bytes, debe funcionar correctamente; etc. etc. Este programa se incorpora a la unidad de testing, y cada noche todos los módulos son compilados, los programas de prueba ejecutados, etc., y por cada error encontrado, se generan mensajes de error que luego son enviados por correo electrónico a los involucrados. Esto es costoso de implementar, pero vale la pena.

Escoger una metodología

Esto sí que es difícil. Algunas empresas siguen CMM (Capability Maturity Model), ISO 900x, y otros. La verdad es que para un productor de software comercial estos métodos significan muy poco: con el tiempo requerido para aprender uno de estos métodos uno podría estudiar medicina. Mi recomendación para los pequeños boliches productores de software es mantener control de versiones, hacer unit testing e implementar algunas prácticas de Extreme Programming, especialmente revisiones de código, pair programming, etcétera.

La Calidad como mística de grupo

Los gringos hablan de corporate culture. En el caso de empresas pequeñas, es mejor hablar de "mística". Tomar la calidad, ponérsela como insignia, y vestirla con orgullo. Sí, señor, sabemos que nuestro software es malo, pero estamos en la mitad del viaje. Solucionamos nuestros bugs apenas los encontramos. Nuestro software está cada día mejor.

Paso a paso.

 

Este sitio es mantenido con ePublish