«ingsoft» realista

INGSOFT

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?

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de magmax

Lo que yo veo

Realmente yo había visto los orígenes del Manifiesto Ágil en sólo dos principios:

  • El cliente no sabe lo que quiere
  • El programador no sabe lo que programa
    • En general, el cliente pide cosas que, si se le dieran tal cual, no se corresponderían con lo que quiere. No es mala intención, sino por otras razones, como por ejemplo que olvida decir ciertas cosas porque está acostumbrado a ellas, porque no está acostumbrado a tratar con un ordenador o porque no es él quien va a usar el software.

      El programador, por su parte, trata de "economizar" su trabajo, e implementa cosas "porque luego será más sencillo hacer otra cosa". En otras ocasiones, "porque es más sencillo así" y finalmente, salen aberraciones que han tardado siglos en terminarse.

      Además, suele estar todo mal probado. El programador suele currarse un entorno de pruebas para una funcionalidad determinada, y cuando acaba, desecha la batería. Si después cambia algo que "rompe" las pruebas iniciales, nadie se entera. Esto puede ocurrir sin querer, al abrirse incidencias contradictorias: al arreglar una, la otra dejará de funcionar.

      En la programación ágil he visto una manera de obtener prototipos casi cada día (en general, uno cada dos semanas-dos meses), de confirmar con el cliente que el camino andado es el esperado, de evitar documentación obsoleta mezclada con la buena y de obligar al programador a separar la interfaz de la lógica de negocio.

      Creo que no hay mucha diferencia con la programación habitual, pero en los detalles está su fuerza.

Miguel Ángel García
http://magmax.org