Hace ya más de 10 años se redactó el “Manifesto for Agile Software Development” con sus 4 valores y 12 principios, un hito importantísimo dentro de la historia de nuestra profesión pero de ningún modo el comienzo del movimiento ágil porque para cuando los próceres se reunieron ya existía cierto consenso, al menos entre ellos, sobre la manera en que se debía desarrollar software. Como miembros respetados de la comunidad y la industria, todo el mundo técnico se sintió representado por los 17, sobre todo porque no eran un grupo de MBAs ni de auditores de calidad ni miembros de algún que otro instituto de normalización o estándares sino personas reconocidas por, entre otras cosas, sus conocimientos técnicos. Y sí, mis “ídolos” Martin Fowler, Kent Beck y  Uncle Bob están allí y son tipos técnicamente fuertes.

El Manifesto no podía esperar más, los procesos de desarrollos eran pesadísimos y todos lo sabíamos y por esto, salvo aquellos que vivían de la ineficiencia (auditores, certificadores, documentadores, analistas de causas, consultores CMMI y recolectores de métricas entre otros), odiábamos el sinsentido. Lo que era evidente que no funcionaba parecía solo ser evidente por los técnicos que despotricábamos todo el tiempo por el estado de las cosas porque la inmensa mayoría de los gerentes de proyecto, y de ahí para arriba, estaban fascinados con la visión “Ingenieril”, pensaban que si lo hacían lo suficientemente bien podrían al fin deshacerse del problema de los desarrolladores y en su lugar reclutar a ejércitos de amas de casa deprimidas por el sobrepeso y obtener los mismo resultados.

Aunque el Manifesto dio un gran empuje, la revolución no iba a esperar por él, si no lo hacían estos 17, lo hubieran hecho otros porque XP ya estaba en boca de todos cambiando las mentes desde abajo de la pirámide. Y es que aunque muchos piensan que esto debemos agradecerlo a los 17, y a las primeras empresas importantes que lo comenzaron a intentar, la verdad es que en toda empresa que yo haya conocido existía al menos uno, y bien respetado técnico, que machacaba, transmitía (“evangelizaba”),  discutía y peleaba por que las cosas cambiaran. Desde las bases, como una guerra de guerrillas. Y al fin, uno por uno, hasta el más escéptico, terminó recitando los principios  del Manifesto mientras se daban golpes en el pecho. (Si hasta el SEI se camufló de ágil, algo similar a ponerle el traje de Spiderman a una anciana de 200 kilos)

Eso es lo que queríamos, cambiar para mejorar. Ese es y ha sido siempre el pensamiento de quienes hacemos de esto nuestras vidas, cambiar para mejorar! Y la cosa mejoró sin dudas, ahora ya tenemos iteraciones, ya aceptamos mejor los cambios, ya nos concentramos más en aquello que da valor pero… ¿qué hay del software?  ¿qué hay de eso de la “excelencia técnica”?. Si si si, hoy estamos mejor pero también es cierto que los técnicos seguimos viendo lo evidente: tenemos un problema muy grave con “la excelencia técnica” que impide que todo esto funcione como debería, como sabemos que debe funcionar. Mientras que hoy la capa de management, mayoritariamente Scrum, está ampliamente difundida, las prácticas de ingeniería por su parte, mucho más antiguas que el mismo scrum, no se implementan (quizás si estás leyendo esto es porque formás parte del 5% de desarrolladores que leen blogs y que implementa alguna de ellas), pair programming casi no existe, TDD muy pero muy poco (muchos se llenan la boca pero el porcentaje de software escrito con TDD es ínfimo), Integración contínua aún cuando es una de las más sencillas todavía está lejos de ser la norma, refactoring hoy se le llama a cualquier cambio suicida (sin tests, sin metodología) y así podemos seguir. Ni hablemos de la formación de los desarrolladores.

El código sigue apestando, esto significa que los diseños apestan, que la calidad sigue lejos de lo que debería ser, esto mismo también significa que los costos siguen altos y que quien invierte en esto puede hacerse de la ventaja competitiva. Pero de todo el movimiento ágil parece que lo que se ha llevado todo es Scrum (y ahora Lean). Pero entre tanta gestión nos estamos olvidando de algo importante: el software y como este se diseña, se programa y se prueba. ¿O acaso está por volver la idea de los monos programadores? ¿Será posible formar equipos de alto rendimiento con maestras jardineras reconvertidas a programadoras?

La verdad es que hoy como ayer, quienes pensamos en cambiar para mejorar, estamos dando una nueva batalla, la de profesionalizar la profesión, la de reforzar las prácticas, la de recrear la carrera técnica (porque el “paraíso” del management (y sus salarios) sigue llevándose a los mejores de entre nosotros), la de formar realmente a los aspirantes para que puedan hacer frente a la complejidad de los desarrollos actuales y futuros, en fin… la batalla sigue siendo por lo mismo: por mejorar la manera en que desarrollamos software. ¿Alguien ve algo malo en esto?

Increiblemente, aunque no veo cómo esto pueda perjudicar a la industria, a la profesión, a los clientes o a la sociedad, hay gente preocupada por el movimiento, personas importantes como Martin Fowler aquí. ¿En qué modo puede un intento por mejorar la profesión, de mejorar y difundir aún más las practicas de ingeniería ser peligroso? El miedo es que se le preste “demasiada” atención a la disciplina y se deje de lado al cliente, el miedo es a que nos perdamos en discusiones ñoñas sobre arquitectura, frameworks, patrones y sesiones de refactoring. Este miedo se basa en la creencia de que podemos volvernos aún mucho más idiotas!. Martin Fowler, quien ha escrito los libros más técnicos que yo haya leído en mi vida parece tener cierto grado de preocupación.

Y sí, yo sé que existe un pequeño grupo de fanáticos que de alguna forma se han sentido traicionados por el rumbo que tomó el movimiento ágil, gente que acompañó al movimiento y que pensó que el camino iba a ser diferente. Después de todo yo también me sentí algo defraudado, pero eso no significa que no aprecie lo que hemos logrado de la mano del movimiento ágil. No obstante, tenemos un problema entre manos, un problema que muchos creyeron que iba a ser resuelto por el movimiento ágil pero que aún persiste y se sigue cargando costos y sigue perjudicando a los clientes.