¿Por qué diseñamos arquitecturas de software a medida ... pero no hacemos lo mismo con las metodologías de software?

(este artículo refleja mi propia opinión)

Creo que, a cualquiera que haya pasado por algún puesto o proyecto de desarrollo de software, no se le ocurriría nunca reusar una arquitectura o diseño de otro producto para un producto nuevo diferente. Usamos, desde ya, patrones e ideas, buenas prácticas y demás, recolectadas durante años, y aplicamos unas u otras para diseñar la arquitectura de un software nuevo según las características que queremos que tenga. Si la escalabilidad es lo más importante, usaremos ciertos patrones, pero si la performance, el footprint u otros temas fueran más importantes, usaríamos otros, o una combinación diferente. Sería absurdo que una aplicación hecha para un dispositivo restringido fuera diseñada con las mismas ideas que un back-end de altísima concurrencia. Cuando diseñamos la arquitectura para un software determinado, entendemos qué características son claves para el mismo (estas características suelen llamarse "atributos de calidad", o "requerimientos no funcionales") y diseñamos acorde a las mismas. Irónicamente, tenemos esto muy claro, pero lo aplicamos muy poco al momento de diseñar formas de trabajo para equipos de productos basados en software.

A lo largo de la historia, han reinado diferentes soluciones metodológicas para el problema de construir software y productos o servicios basados en software. En todos los casos, cada solución fue diseñada para un conjunto de "atributos de calidad" que fueron importantes para los entornos de trabajo en los que fueron diseñados, pero típicamente, luego se llevaron tal como estaban a otros entornos, asumiendo que funcionarían igual de bien. En otras palabras, es la misma idea de reutilizar una arquitectura hecha para un sistema de un tipo para cualquier otro sistema, no importa el tipo, pero aplicada a metodologías. Cuando hablamos de sistemas de software, suena absurdo pensar en esta idea de "encajar una arquitectura con calzador", pero cuando hablamos de metodologías de software, es sumamente común. Como mencioné antes, las metodologías fueron diseñadas en un contexto que puede ser muy diferente en distintos momentos del tiempo, en distintas organizaciones, y demás. Algunos ejemplos, para ir pensando ...

• El método "Surgeon Team", ideado por Harlan Mills y divulgado en el famoso "Mythical Man Month" de Brooks propone que todo el desarrollo gire alrededor de un "programador jefe" y que existan toda una serie de roles alrededor de él, para que pueda tener control intelectual del software y que su tiempo pueda ser aprovechado al máximo. Este método o forma de organización fue pensado en un momento donde no existían herramientas de colaboración, no existían carreras y estudios especializados en ingeniería de software, mucho del software se escribía en papel y luego se pasaba a tarjetas, y claramente, los pocos que entendían de esta "nueva ciencia" debían tener el control. Hoy, este método que fue ideado hace décadas, no aplica. Quizás la idea de "programador jefe" podría aplicar en ciertos contextos, como aplicaciones muy críticas y con riesgo de vida.
• El método "Cleanroom Software Engineering", también ideado por Harlan Mills entre los 70s y 80s, propone que se realicen rigurosas pruebas de escritorio sobre un programa incluso antes de compilarlo, porque si un programa llega al compilador con defectos, se asume que ya nació con baja calidad. Nuevamente, tenemos que ubicarnos en el contexto donde nace tal método. Arquitecturas basadas en mainframes, con acceso muy limitado al compilador e incluso programación todavía con tarjetas perforadas. Cada vez que alguien llegaba al compilador con un programa que no compilaba, le quitaba preciado tiempo de compilador a otros miembros del equipo. Esto, sumado a la criticalidad del software a construir (Cleanroom fue pensado para software críticos, como defensa, etc), hacía que tenga sentido hacer pruebas cuasi matemáticas del software antes de compilarlo siquiera.

En lo anterior, los atributos de calidad perseguidos tenían que ver no sólo con el software, sino con el entorno en el cual se desarrollaba el software, que era caro y escaso. Se buscaba minimizar defectos, y a la vez, optimizar el recurso de compilación. Claro que, si uno ve los casos anteriores, tan distantes, podría decir que las cosas eran tan diferentes por entonces que no tiene ni sentido llevar estas ideas al mundo actual. Así que, en virtud de esa potencial objeción, pensemos en casos un poco más recientes ...

• El marco metodológico del CMMI (que no es una metodología en sí misma, sino que define características que un proceso maduro de software debe tener) primaba ante todo la repetitividad de los éxitos en proyectos de desarrollo de software. El primer CMM (antecesor del CMMI) nació con la necesidad de "catalogar" a contratistas del Departamento de Defensa de Software, distinguiendo aquellos que eran capaces de "cumplir" (con tiempo, calidad, etc) en forma más consistente (o repetible) de aquellos que no. Además, el CMMI está muy pensado para una relación "cliente / proveedor" o "usuario / equipo de desarrollo" muy marcada, estableciendo contratos y controles muy claros respecto al alcance, requerimientos y demás. Si me dedico a hacer proyectos de alcance más o menos cerrado y de índole similar (ej. sobre un conjunto de tecnologías y en un dominio de negocio bastante estable), el CMMI puede andar muy bien.
• Las variantes de metodologías ágiles, en sus orígenes, estuvieron orientadas casi exclusivamente a responder al cambio en los proyectos de software (de hecho, el subtítulo del primero libro de XP de Kent Beck es "embrace change"). Nacieron en una época en donde ya existían tecnologías que permitían experimentar y prototipar más rápido (en particular, Smalltalk) y en entornos mucho más de negocios que gubernamentales o militares, donde una organización quería encarar un gran producto "nuevo" que quizás no tenía del todo claro cómo construir. En general, también, nacieron en entornos de gente muy buena técnicamente, que encontró que no necesitaba de tanta documentación formal, sino de interacción fluida y constante a "usuarios" con quiénes pudieran construir juntos.

En el intento de expandir cosas como las anteriores a diferentes entornos, empezaron a surgir parches de diferente tipo. En mi época de consultor de CMMI, siempre nos dábamos un poco contra la pared al querer "modelar" el mantenimiento continuo de un software con los conceptos de CMMI, que giraban todos alrededor de la idea de "proyecto" (lo cual tiene sentido si recordamos qué motivó su origen) y terminábamos armando cosas como "proyectos de mantenimiento" para calzar la realidad con el modelo. Hoy en día, varios de los conceptos de "agilidad en escala" (como los PI Planning de SAFe) no son más que agregados para tratar de hacer calzar los métodos ágiles en entornos que requieren algún nivel de predecibilidad, o que tienen una complejidad o tamaño tal que no son soportados por los métodos tal como fueron ideados originalmente. Esto no es necesariamente malo, y para mí el PI Planning es una buena idea en muchos contextos, pero es importante entender que son adaptaciones que surgen de "estirar" el método ... y estirarlo más de la cuenta puede ser riesgoso.

En los primeros años de la agilidad, principios de los 2000, surgió una idea muy buena por parte de Alistair Cockburn, una de las voces más reconocidas de la agilidad. Alistair decía que "agilidad" es algo diferente para un proyecto de 1000 personas y cuyo software puede poner en riesgo la vida de las personas, que, para un proyecto de 10 personas, cuyo impacto de falla era meramente una molestia menor. Decía literalmente, "una metodología por proyecto" y diseñó una familia de metodologías llamadas "Crystal" que se adaptaban a diferentes contextos y situaciones. La idea de Allistair me parece excelente, cabal y acertada. La usamos, con varios compañeros, en la era del CMMI, e incluso la rescaté en la era de la "multimodalidad", hace unos 5 o 6 años atrás. Lamentablemente, en su momento XP y Scrum le pasaron por arriba a Crystal (supongo que es más vendible pensar que "una sola cosa sirve para todo" que pensar en diseñar un método ad-hoc cada vez) y si bien creo que llegó a publicarse el primer libro (Crystal Clear) no tomó mucho vuelo. Hace poco vi que el libro de Crystal Clear volvió a editarse y Alistar volvió a hablar del tema, lo cual es un rayo de esperanza.

En estos tiempos en los cuáles, luego de una gran ola de adopción de agilidad a escala, reina el escepticismo hacia todo lo ágil, creo que es muy importante rescatar esta idea de que no todo es igual. Si estoy desarrollando un producto innovador y maleable, un enfoque será mejor que otro. Si estoy desarrollando un producto más predecible, pero muy crítico, el enfoque será diferente. Si estoy prototipando una idea, el enfoque será, a su vez, otro. No existe una receta única para los equipos de desarrollo, diseño o mantenimiento de software. La forma más adecuada para un equipo u organización tendrá elementos de un método u otro, de la misma manera que una arquitectura de software para un sistema tendrá algún patrón u otro, según los atributos de calidad perseguidos lo requieran. Esta crisis de la agilidad, como toda crisis, es una gran oportunidad. Una oportunidad para rescatar el sentido común en el diseño de metodologías, de dejar atrás los fanatismos ciegos, de diseñar formas de trabajo que tomen lo mejor de cada enfoque previo ... y de recordar de que no existen balas de plata en el software, como ya lo dijo el gran Fred Brooks.