Hace muchos muchos años en una tierra muy muy lejana, mientras hacía la Tesis Doctoral, leyendo todo lo que se hubiera escrito en la Galaxia sobre diseño OO, di con un inspirador artículo, escrito por un tipo que no es nada conocido y que, desde aquello, poco más «famoso» ha escrito.
Aquel artículo se llama «Assessment of Design Patterns during Software Reengineering: Lessons Learned from a Large Commercial Project», y el autor es un tal Wendorff, y fue publicado en la CSMR (European Conference On Software Maintenance And Reengineering) de 2001 (aquí el enlace a ieeexplore).
Aquel artículo me resultó bastante inspirador y aún hoy, años después, sigo recordándolo cuando veo muchas situaciones en estos tiempos Ágiles.
Resumidamente, por si no te lo vas a leer (que ya nos conocemos), y escribo de memoria, el artículo cuenta la mala experiencia que sufrió cierto departamento al intentar mejorar la mantenibilidad de su software añadiendo, sin control, patrones de diseño. Se añadieron sin control porque estaban de moda y porque realmente nadie había profundizado en qué efecto tendría aquello (a que ya te suena, cambiando patrones por otras tantas cosas).
Como consecuencia de lo anterior, se multiplicó el tamaño del software (más clases, más líneas de código), se hizo más complejo entender el diseño (aun siendo más flexible) y se llegó a una situación peor que la que había antes de ponerse a introducir descontroladamente patrones.
Hubiese sido más sensato añadir un número mínimo de patrones sólo en aquellos lugares en los que realmente se estaba modificando mucho el código, mejorando así la «cambiabilidad». Pero aquello no se pensó, como tantas cosas no se piensan y se hacen sin saber muy bien la razón.
Desde entonces, me viene a la cabeza aquel artículo cuando veo a gente (y por extensión organizaciones) aplicando supuestas buenas prácticas, de cualquier tipo, sin control, sin saber la razón, sin ponerse a pensar en qué medida o si sería mejor invertir su tiempo en hacer algo más beneficioso.
Cuántas cosas hacemos sin saber la razón, el para qué, ni los efectos, sin tener claro cuál es el «fin» y cuáles los «medios». Y que cantidad de problemas trae eso. Horas en crear y horas en eliminar lo que era innecesario (o peor, dejarlo ahí).
Ciertamente, saber los efectos de mal aplicar una práctica, promover la reflexión de qué objetivo buscamos, etc., requiere de profesionales preparados… pero de eso iba esto ¿no? ¿o es que queremos jugar la Champions con 4 Ewoks aficionados?
Los que escribieron el manifiesto Ágil, aquellos viejos programadores, debieron haber vivido muchas situaciones similares y, quizá por ello, añadieron aquel principio Ágil de «la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial».
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
No me he leído el artículo que indicas, pero he vivido el tema de los patrones, y la sobreingeniería. Quizás sea de los viejunos que se inspiran por la experiencia.
Cuanta sabiduría hay en «maximizar la cantidad de trabajo no realizado».
Cuando era junior me tocó mantener un código construido con infinidad de patrones y herencia que realmente no eran necesarios porque la tarea era bastante sencilla.
También lo contrario, clases y JSP kilométricas que no compilaban por ser demasiado grandes…
Excelente post gracias Javier!