A partir de los años 70 comenzó a desarrollarse lo que, según mi opinión, es la falacia de la Ingeniería del Software y sus métricas para la cuantificación y planificación de proyectos de software. Desde las simplistas
LOC (Lines Of Code), hasta la
Complejidad Ciclomática, las métricas de producto han ido cambiando desde enfoques tan extremadamente matemáticos como inútiles, hasta enfoques de pesadas y burocráticas metodologías y análisis de negocio para los cuales hay que documentar durante cuatro meses para un proyecto de dos.
Es ahora, en el reciente 40 cumpleaños de la denominación de "Ingeniería del Software" como disciplina, cuando por primera vez uno de los padres del
Análisis Estructurado, Tom DeMarco, en un
artículo autocrítico realmente sorprendente (tratándose de él) reconoce con honestidad que la
Ingeniería del Software es una idea obsoleta y que el Desarrollo de software es algo experimental, al menos en su concepción.
Durante este tiempo, la mayor parte del
stablishment académico ha insistido de forma machacona a los sufridos universitarios de informática con la última metodología que aprendió (pero que jamás aplicó en ningún proyecto empresarial) el profesor de turno cuando tomó su plaza titular y en la que se anclaría de por vida, mientras se sucedían las promociones de informáticos que quedaban frustrados en su primer proyecto laboral por dos razones: la primera, porque la metodología en uso ya estaba "desfasada"; la segunda porque obviamente, resultaba impracticable para la mayor parte de los proyectos del mundo "real".
En efecto, es una trampa porque se trata de una falacia que persiste una y otra vez en un mundo endógeno. Los creadores de las métricas y de las metodologías vienen de monstruosos proyectos militares o gubernamentales, o del mundo académico. Mientras en el mundo académico éstas se toman como una "ciencia", como una verdad absoluta y dogmática, aunque jamás la hayan aplicado o la hayan visto aplicar, los casos de éxito en los grandes proyectos son nulos... ni que decir tiene del 99% restante de proyectos medianos para los que no fue ni imaginado. Y así, se suceden nuevas metodologías cada cinco años, una tras otra, que se van "enseñando", en la confortable ilusión de que algún día servirá a alguien, o de que esta sí es la "bala de plata" definitiva, aunque su uso/éxito real sea casi anecdótico o nulo.
La falsa ilusión del control
La ingeniería del software es una falacia porque es una aserción que podría estar compuesta por verdades parciales, pero que es falsa en su conjunto. Durante mucho tiempo se ha transmitido la idea del desarrollo del software como algo medible con exactitud, con el rigor científico aplicable a elementos físicos cuyos precisos procesos de fabricación son conocidos y estandarizados desde hace años... como comentó Dijkstra en un interesante ensayo: "...
que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores" ([1]).
Todo esto para lograr prácticas consistentes y predictibilidad. Y en parte, en efecto, es así. Las sucesivas metodologías han ido aportando buenas prácticas que han servido, en los proyectos en los que es posible, un análisis más exhaustivo y pormenorizado de los requisitos, trazabilidad, control de cambios, control de calidad, etc... El problema es que han transmitido y calado en la conciencia colectiva empresarial una falsa ilusión de control del proceso. Esta ilusión también ha calado en el mundo académico, (demasiado separado, por cierto, del mundo profesional) donde parece que preocupa más la lírica teórica que la formación de profesionales prosaicos, que es lo que el mundo necesita, en definitiva. Pero también ha calado incluso en los mismos profesionales, que pinchan en hueso constantemente intentando aplicar aquellas prácticas y métricas aprendidas que teóricamente les alejan y diferencian de la "artesanía" de los sistemas de información de antaño, porque han recibido una formación en la que les han asegurado que "esto" nuevo, es "ciencia".
Pero la verdad es que la mayor parte de las decenas metodologías y métricas de estos últimos 40 años no son más que un conjunto de buenas prácticas adornado con estadísticas desplegadas con un imponente soporte matemático. Decenas de metodologías con una relación de casos de éxito tan exigua, que en cualquier otra disciplina científica no serían consideradas. Y hoy día, ninguna de ellas se aplica con éxito de forma generalizada ni se ha convertido en estándar, ni garantiza el éxito de la "fabricación"... y aun así se sigue llamando "ingeniería". Imaginen, por ejemplo, metodologías quirúrgicas con anecdóticos casos de éxito... ¿Se enseñarían en las facultades de medicina como "metodologías a aplicar"?.
El objetivo de las metodologías ha sido siempre la de aumentar la productividad y la calidad del desarrollo del software permitiendo que éstos sean sistemáticos, predecibles y repetibles. Hoy sabemos que las métricas y el control de calidad cuestan mucho tiempo y dinero... ya hace más de 20 años que sabemos que "el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia" ([1]). Aun así se sigue manejando el término control de calidad como si
realmente pudiéramos controlar
de verdad la calidad del software. Se habla de las metodologías como si realmente hubiesen conseguido el objetivo para las que fueron creadas. Ésta es la falacia.
Los ladrillos de código
Yourdon/DeMacro, Merisse, SSADM, Métrica (nuestro particular
"me too" a modo de refrito de modelo de procesos y formas de llevarlo a cabo: dos por uno, oiga)... todas las metodologías a las que me he acercado están orientadas correctamente al proceso y a la funcionalidad, pero ignorando o trivializando unos de los aspectos fundamentales, que es tratado a menudo como un
"recurso" de un determinado
"perfil": los programadores, los hacedores del proceso mismo. En todos ellos, los
recursos se mueven entre tareas o a lo largo de proyectos al más puro estilo de las obras civiles como si fuesen elementos pre-formados, estáticos, constantes, clónicos, sustituibles e inalterables. De la misma forma que las máquinas excavadoras ("Máquina A: X metros cúbicos por hora"), los programadores son capaces de realizar "una funcionalidad X en una unidad de tiempo Y". Ja, ja.
Y nos lo creemos. Nos han hecho creérnoslo, y seguimos
haciendo como si fuese verdad. En el mantenimiento de esta mentira participamos todos (unos más que otros, eso si) pero especialmente es una cadena de mentiras necesarias. El cliente necesita creerlo y necesita que le digamos que estará en determinada fecha, y le enseñamos complejos cronogramas llenos de hitos y gantts que terminan, qué casualidad, justo en la fecha que él desea. El comercial también lo necesita porque hay que vender el proyecto. El gerente tiene dos opciones: el cinismo de créerselo o la resignación... normalmente acaba en la primera. Y asi una y otra vez. Clientes descontentos, equipos quemados buscando otra empresa, proyectos desastres inmantenibles, etc...
La cultura corporativa nos exige y nos sugiere permanentemente algo que sabemos positivamente que es falso, pero en lo que se insiste una y otra vez: la semejanza entre los proyectos de desarrollo de software con los proyectos de edificación u obras. ¡Como si fueran comparables!. En los primeros hay procesos de fabricación fiables, comprobables, y certificados. Hay procesos de construcción definidos desde la ciencia y la experiencia de cientos de años. Hay materiales probados, con tolerancias comprobadas y medidas. En definitiva, en los primeros se hace "ingeniería", en los segundos no. Es así de sencillo. Y las titulaciones adquiridas no tienen menos valor por lo que estoy diciendo. Tampoco diagnosticar una enfermedad u operar un corazón es ingeniería y no tienen menos valor los títulos en medicina por eso.
Adivina quién viene a cenar o el factor humano.
Lo curioso de todo esto es que "
el método" falla en lo más importante. Y es que al final, tras las buenas prácticas, la toma de requisitos, el análisis, el diseño, el control de calidad y la documentación, el cliente está esperando los únicos dos parámetros que le interesa: tiempo y dinero. Aquí es donde "
el método" se viene abajo o, simplemente, no sabe/no contesta. ¿Por qué? Muy sencillo. Porque ahora es donde entra en juego la estimación, es decir, la predicción, la pronosticación. Y esto no parece muy científico que digamos. Y aquí no contamos con buenas estadísticas de trabajos mecánicos y repetitivos como en obras de edificación. Aquí no hay paredes estandarizadas, ni obreros equivalentes... Aquí nos encontramos con equipos de distinta experiencia en distintas áreas tecnológicas, con equipos con su propio ciclo de vida y sus modus operandi distintos. Personas muy distintas con experiencias y destrezas muy diferenciadas. Y dichas diferencias tienen un impacto brutal en el resultado (rendimiento, mantenibilidad,
limpieza, etc...).
Sinceramente, nunca me he encontrado a nadie que aplique métricas tipo
COCOMO (¿de verdad alguien se cree que ése tipo de técnicas es precisa?). Al final, todas las técnicas predictivas utilizadas se basan en la experiencia de una forma u otra: bien por analogía con otros proyectos, bien por experiencia personal individual o en grupo (
Wideband delphi).
Además, hay dos aspectos fundamentales del factor humano a tener en cuenta:
- Especialización. En el desarrollo hay una tremenda especialización. Las distintas tecnologías forman a expertos no intercambiables y, por supuesto, nada tiene que ver un proyecto de una aplicación empresarial con un proyecto de un software de desktop o un videojuego, por ejemplo. Esta especialización hace que cierto programador pueda ser tremendamente eficiente en un proyecto y nada eficiente en otro.
- Formación. Todo proceso de programación lleva implícita una parte más o menos grande de formación, que puede ser un porcentaje alto del tiempo dependiendo de la experiencia del desarrollador en la tecnología.
Sin duda, la variable más compleja de manejar es la del factor humano, ya que las estimaciones se pueden ir al traste con mucha facilidad. Los proyectos medianos con equipos medianos son especialmente sensibles, ya que la dependencia del equipo humano es el factor importante: no es lo mismo repetir con un equipo que ya ha trabajado junto que con un equipo nuevo... no es lo mismo poner a doce programadores inexpertos que a seis expertos. Y ya sabemos que, en muchos casos, incorporar al señor XY en el proyecto es una buena razón para tener ocupado a XY, no para que el proyecto termine antes o lo haga con más calidad.
Tell me sweet little lies
Parafraseando la famosa canción de Fleetwood Mac (Little lies), ha sido la industria del software la que se ha fijado mantener la mentira y encargarse de que se cuente mil veces (especialmente en la universidad, donde parece que se dan menos cuenta) para que, así, a fuerza de repetirla, acabe en algo cierto. Pero los los procesos de desarrollo aún distan mucho de ser medibles, predecibles, estables y repetibles. Lo que se ha venido en llamar (y es posible que desde ahora empiece a dejar de hacerlo)
"ingeniería" del software aún está en pañales y le queda muchísimo camino por recorrer. Es posible que algún día, se parta de unidades básicas estándares (procesadores estándares, sistemas operativos estándares, lenguajes estándares, procesos estándares...) pero supongo que yo no estaré aquí para verlo.
Como comentaba en mi
primer post, no todos los desarrolladores experimentados son expertos. El factor humano es la columna vertebral de los desarrollos y se requiere que los proyectos tengan una orientación al equipo tanto como lo hacen al proceso. Es fundamental. Es más, se precisa que sean los proyectos los que se asignen a los equipos y no al revés. Hoy por hoy, la experiencia sigue siendo la forma generalizada e imprecisa de realizar las estimaciones.
[1]: El ensayo comprometido y crítico de Dijkstra es demoledor. En castellano, aquí.
Entradas
