La Ingeniería del Software cumplió 40 años el pasado 7 de octubre.(2008) Son los que han pasado desde la conferencia de la NATO(1) en la que se dio nombre y origen a esta nueva ingeniería, necesaria para acabar con los fracasos del software, que generaban sobrecostes millonarios en los proyectos militares.
La “tesis” de conocimiento que inició la evolución dialéctica para esta disciplina profesional, aportó dos principios: precisión en los requisitos y gestión de los proyectos basada en la planificación y el control.
25 años más tarde la agilidad supuso la antítesis de estos principios, porque no funcionaban en los proyectos que no necesitan previsibilidad, sino rapidez e innovación continua.
Si errar es humano y rectificar de sabios, Tom DeMarco es de los segundos. Su obra es una de las principales contribuciones al desarrollo de la Ingeniería del Software.
Es autor de uno de los principales trabajos sobre métricas para la gestión de proyectos de software, referente de temarios como PMBoK: Controlling Software Projects: Management, Measurement and Estimation, publicado en 1982, hizo famoso su principio “no puedes controlar lo que no puedes medir“. Con motivo del 40 cumpleaños de la Ingeniería del Software , el número de julio/agosto de IEE SOFTWARE publilca un artículo de Tom DeMarco que cito literalmente:
Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no.
Tom DeMarco, autor del axioma: “Usted no puede controlar lo que no puede medir”, afirma ahora que el control puede no ser importante en muchos proyectos de software:
“Muchos proyectos han avanzado sin centrar la gestión en el control, sino en la creación de productos maravillosos como GoogleEarth o Wikipedia.
Para entender la verdadera función del control, es necesario distinguir de manera drástica entre dos tipos diferentes de proyectos:Un proyecto de tipo A, con un coste estimado de un millón de dólares y un cálculo de retorno aproximado de 1,1 millones.
Un proyecto de tipo B, que con un coste estimado de un millón de dólares, produce un valor de más de 50 millones de dólares.Lo inmediatamente evidente es que el control resulta importante en el proyecto A, y sin embargo su importancia es mínima en el B. Esto nos lleva a la extraña conclusión de que el control estricto es importante en los proyectos poco importantes, y viceversa.
El artículo hace un paralelismo con el tipo de control de un padre sobre su hijo y me recuerda el principio de “control sutil” identificado por Nonaka y Takeuchi en el concepto original de Scrum.
“Al aplicar el principio ‘no se puede controlar lo que no se puede medir’ a la educación en la adolescencia, la mayoría de las cosas realmente importantes, honor, dignidad, disciplina, personalidad, valores, ética, ingenio, lealtad, humor, bondad… no son medibles.
Tienes que formar a tu hijo lo mejor que puedas sin tener feedback de métricas. Es difícil, porque ser padre es difícil. Tienes unas ciertas métricas del tipo de las notas del colegio, e intuyes que la nota de matemáticas es más importante que la de español y que la nota de comportamiento quizá diga más del profesor que del alumno”.
Cuestionar el conocimiento lo hace avanzar(2).
(1) Conference on Software Engineering. 1968 Garmisch, Alemania.
Informe de la conferencia
(2) Desde sus Ideas iniciales en la línea de “No puedes controlar lo que no puedes medir” a las conclusiones actuales sobre métricas, pasando por las que a finales de los 80 resumía al afirmar “La mayoría de los problemas de nuestro trabajo no son tecnológicos sino sociológicos” (Peopleware: Productive Projects and Teams 1987)
