El 7 de octubre cumplió 40 años la Ingeniería del Software, porque 40 son los que han pasado ya desde la conferencia de la NATO(1) que bautizó a esta nueva disciplina profesional, nacida para solucionar los desplantes del software en los proyectos militares, a los que hacía perder millones de dólares porque siempre entregaba tarde mal y nunca.

Hace 40 años que se lanzaron las primeras balas trazadoras hacia las soluciones, aunque quienes las disparaban pudieran creer que eran ya tiros certeros y definitivos.
Incluso aunque los que aún siguen a pie juntillas su estela, piensen que se trata de la meta del conocimiento, y no un punto del camino (concretamente el inicio v. síntesis)

Cuanto más nos empeñamos en seguir la trayectoria, sin corregir el tiro, más agrandamos el ángulo de error, y más nos alejamos del objetivo.

En las direcciones iniciales de la Ingeniería del Software, estaban: rigor y precisión en los requisitos y diseño del producto, y la planificación y control del proyecto.

Eran soluciones como todas: de y para su contexto. Un contexto de grandes proyectos militares con pérdidas millonarias en los sub-sistemas de software; y sería torpe criticarlas por no servir para proyectos diferentes en un escenario tecnológico 30 años más evolucionado. Criticarlas por pesadas e inadecuadas para pequeñas "start-ups" o grupos que no programan el guiado de misiles balísticos, y que no necesitan previsibilidad sino rapidez e innovación continua.
Como también es torpe es no cuestionar lo que hacemos.
Considerar que la solución que nos han enseñado es válida para todo, y en todo momento. Para todo, convencidos de que nuestro nuevo traje de ceremonia resulta apropiado para cualqueir ocasión. Y en todo momento, con una "actitud Peter-Pan" que no quiere evolucionar profesionalmente.

Si errar es humano y rectificar de sabios, Tom DeMarco es de los segundos. Su obra es una de las principales contribuciones en el desarrollo de la Ingeniería del Software.

Es autor de uno de los principales trabajos sobre métricas en la gestión de proyectos de software, referente de temarios como PMBoK: Controlling Software Projects: Management, Measurement and Estimation y con motivo del 40 cumpleaños de la Ingeniería del Software , el número de julio/agosto de IEE SOFTWARE publica un artículo, en el que, mejor que comentar nada; y no sé si usando o abusando del derecho de cita, prefiero pegar literalmente sus palabras:

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 es también el autor de la afirmación que en las últimas décadas ha sido axioma para muchos modelos de procesos y gestión (¿todos?) "Usted no puede controlar lo que no puede medir".
Y ahora, su autor afirma 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 extricto es importante en los proyectos poco importantes, y viceversa.

Me viene a la cabeza el principio de "CONTROL SUTIL" identificado por Nonaka y Takeuchi en los Campos de Scrum al seguir leyendo en el artículo la comparación que dibuja con el tipo de control que un padre realiza en la educación de su hijo adolescente:

"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 quzá diga más del profesor que del alumno".

Para quienes creemos que el conocimiento está en continua evolución , y que en ocasiones se llega hasta la náusea desarrollando líneas de métricas y gestión inapropiadas para muchos proyectos, Leer estas afirmaciones de Tom DeMarco reconforta y da gusto ver que hay personas que con honestidad cuestionan, depuran y mejoran de forma continua(2). Que a fin de cuentas afirman que los años de experiencia les hacen cuestionar y mejorar.

Claro que esto es lo que me parece a mi. Seguramente quienes prefieren métricas de la línea PSP, y modelos CMMI para todo, opinarán que Tom DeMarco es una pena. Con las buenas ideas que tenía, y ahora se ha echado a perder. Se ha pasado al lado oscuro. :-)

*Artículo Software Engineering: An Idea Whose Time Has Come and Gone?

(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 y gestión de proyectos (ágil, por qué no decirlo), pasando por las que a finales de los 80 resumía en su afirmación "La mayoría de los problemas de nuestro trabajo no son tecnológicos sino sociológicos" (Peopleware: Productive Projects and Teams 1987)


Fuente: http://www.navegapolis.net