«ingsoft» realista

Después de unas cuantas décadas desde la «crisis del software», las cosas no han mejorado demasiado en las ciencias de la computación. El desarrollo de programas de computadora dista mucho de parecerse al proceso de fabricación típico de cualquier otra ingeniería; razón ésta por la que muchos consideran, no sin falta de razón, que el prefijo «ingeniería» le viene grande a la informática.

El ingsoft es el intento de resolver este problema, aunque más que «ingeniería del software» quizá debería llamarse algo así como «des-artesanización de la informática». Personalmente coincido con Dijkstra en que la verdadera ingeniería del software vendrá necesariamente de la formalización y las matemáticas, y para eso queda todavía «mucha tela que cortar y muchos metros de pan que comer» que diría E. Dominguez.

Mientras esperamos, unos cuantos gurus se reunieron (en 2001) para intentar aclarar sus ideas al respecto y redactaron lo que se conoce como el Manifiesto Ágil. El manifiesto expresa unos valores y principios bastante chocantes para muchos en relación al «ingsoft» tradicional. No los voy a comentar aquí, lee el artículo de la wikipedia que he enlazado o directamente la página del manifiesto, que está mejor explicado de lo que podría hacerlo yo.

Lo que si me gustaría enumerar son las premisas que yo entiendo (me puedo equivocar) que llevaron a esas conclusiones. Creo que el manifiesto es el resultado de admitir sin tapujos la dolorosa realidad, cosas que creo que todos los que hacemos software pensamos en el fondo:

• Predecir el futuro no está al alcance de cualquiera. Prever (en el sentido literal de la palabra) todas las variables que pueden influir en el diseño e implementación de una aplicación mínimamente compleja es básicamente imposible, o tan difícil que merece más la pena invertir ese esfuerzo (o una buena parte) en prepararse para los cambios, los que sean y ocurran cuando ocurran. En decir, en lugar de preparar un plan de contingencias por si hay cambios inesperados, asumir que los habrá, como parte de la filosofía de trabajo.
• Las estimaciones de plazos siempre fallan. Esto no deja de ser más de lo mismo. No es que las estimaciones sean malas, el problema es que no hacemos estimaciones, hacemos patéticos intentos de adivinación. Estimar (en el sentido estadístico) es ofrecer un valor aproximado a partir de un conjunto de datos previos. Es decir, para saber cuánto se va a tardar en hacer una tarea se consulta la información sobre tareas similares en el pasado (para lo cual es imprescindible medir y registrar cada nueva tarea) y se determinan cuestiones como formación del personal que la hizo, novedad de la tarea, tamaño del equipo, calidad del resultado, etc. Después se compara con la tarea actual y se extrapola en la medida de lo posible…. Ahora compara lo dicho con lo que hace el comercial de tu empresa. Si no estás llorando es que el comercial de tu empresa eres tú.
• Los requisitos siempre cambian. Una ERS escrita y firmada con sangre es papel mojado (y no me refiero a la sangre). El propio desarrollo del proyecto es un medio para que el cliente entienda lo que quiere realmente Es cuasi-imposible tenerlos todos claros antes de empezar y que no haya que añadir, cambiar, quitar algunos/muchos de ellos durante y después del desarrollo. Te puedes repetir un millón de veces que es posible escribir una ERS intocable pero sabes que te estás engañando, nunca ha pasado y nunca pasará.
• Los planes detallados acaban por abandonarse. Es difícil justificar el esfuerzo que supone un plan detallado al comienzo de un proyecto. Es útil hacer planificación de grano grueso, pero es mejor dejar la planificación detallada para cuando comienza el desarrollo de cada componente o iteración concreta.
• Las fases de análisis, diseño, desarrollo y pruebas se solapan constante e inevitablemente. Es contraproducente aislar estas fases porque las interrelaciones entre ellas son constantes. Un programa no es un puente o una carretera, no se fabrica del mismo modo y el cliente lo sabe.
• Es imposible diseñar una aplicación completa antes de programar nada. El diseño es un proceso de «descubrimiento». Solo en contadas ocasiones y con mucha experiencia en el campo se puede hacer un diseño completo «a ciegas».
• El diseño está influenciado por el lenguaje y las herramientas. O dicho de otro modo, la elección del lenguaje, herramientas y entorno de desarrollo (incluso del personal) son determinantes en las decisiones de diseño.
• La documentación prematura es un lastre. Código legible, pruebas claras y comentarios «extraibles» son la mejor documentación que puede tener un programa. La literatura es costosa de mantener y es fácil provocar ambigüedades entre requisitos, documentación y código. Los podemos fustigar por no haber hecho primero la documentación, pero eso no cambiará nada.

Y por supuesto:

• MENOS ES MÁS
• LA CREATIVIDAD ES LA ESCLAVITUD
• LA EXPERIENCIA ES LA FUERZA

¿Alguna más?