Hace un par de entradas recomendé el libro de Kent Beck, "Extreme Programming Explained". Tuve que releer los primeros capítulos en vistas de una clase que tenía que dar sobre "Modelos de desarrollo", en el marco de la Materia "Construcción de Aplicaciones Informáticas" de la Facultad de Ciencias Económicas (UBA).
Lo de arriba no es sólo autobombo (que hay algo de eso, por qué no), sino que quiero subrayar que, dado que el marco es el de las ciencias económicas, me centré exclusivamente en esos aspectos de las bases de la metodología que plantea Kent Beck.
Tuve al releerlo la misma impresión que cuando lo hice por primera vez. Comencé un poco distraído, pero el libro fue atrayendo toda mi atención hasta llegar al capítulo 5, "Cost of Change", después del cual tuve que dejar de leer. Para cualquiera (no demasiado joven) dentro del ambiente de desarrollo de sistemas, ese capítulo se siente como un mazazo que rompe con todo lo aprendido hasta el momento. Voy a comentarlo.
Empieza con un grafiquito muy simple y simpático que todos los que transitaron por alguna facultad recordarán:
Es decir, lo que todos sabemos: el costo de un cambio (actualización, corrección, mejora, lo que sea) crece desde el diseño hasta la puesta en marcha y desde allí se dispara dramáticamente.
Claro, si estoy en diseño y veo la nececidad de cambiar la relación entre dos tablas de la base de datos, el costo de corregirlo será el de un par de minutos con el programa de diseño que esté utilzando para crear el modelo. Si tengo la misma necesidad, pero la base de datos está en producción, llena de registros vitales para el cliente, talvez geográficamente muy lejana, los costos en tiempo y dinero son incomparables.
Por eso la obsesión por la perfección en las primeras etapas del desarrollo, muy marcada en las metodologías tradicionales: los requerimientos deben ser completos, el modelo debe ser perfecto, los programadores deben seguirlo al pie de la letra, tratando de arruinarlo lo menos posible. Como en general no son (somos) gente muy capaz, cometerán (cometeremos) un sinnúmero de errores que nos (les) costarán (¡a uds.!) muchísimo dinero. Así que hay que gastar mucho (pero menos que muchísmo) en testers, control de calidad posterior al desarrollo, y también en estrictos métodos formales de control de la "producción" (la codificación)... me pregunto por qué nunca se puso de moda "debemos gastar mucho dinero en prestaciones para atraer a los mejores prospectos, formación para tener a los mejores programadores y en sueldos altísimos para que se queden con nosotros" si el principio es el mismo (aunque hay que reconocer que estamos mucho mejor que antes).
Se nos ha enseñado que el software se degrada naturalmente con el mantenimiento y las modificaciones, que nuestro esfuerzo de buenas prácticas, claridad, simplicidad y código mantenible es una utopía a la que debemos tender para maximizar el rendimento pero irrealizable por definción, y que el software, como cualquier otro producto, se gasta con el uso y muere.
Pero ese dibujito es largo más viejo que yo. Está basado, me imagino (aunque no lo sé realmente), en los sistemas de producción fabril de donde se derivaron las primeras metodologías para el desarrollo de software. En un principio el desarrollo de software se encuadró en el modelo de desarrollo de cualquier producto, por ser el único que existía: la planificación de la producción, alegoría para la modelización de un sistema, es más valorado (personal de cuello blanco) que la construcción física del producto (obreros de cuello azul), la fábrica, la cadena de montaje, Tiempos modernos y todo eso, alegoría de la codificación del sistema.
Kent Beck plantea (y yo estoy de acuerdo, con matices) que si alguna vez eso fue cierto ya no lo es. Para ponerlo en sus propias palabras:
The software development community has spent enormous resources in recent decades trying to reduce the cost of change—better languages, better database technology, better programming practices, better environments and tools, new notations. What would we do if all that investment paid off? What if all that work [...] actually got somewhere?
Tenemos computadoras con las que podemos compilar enormes sistemas cuantas veces querramos sin costo, programación orientada a objetos, administradores de bases de datos, entornos que nos ayudan a modificar dramáticamente la estructura del sistema con relativa facilidad. Tenemos redes de altísima velocidad, administración remota de equipos, podemos trabajar prácticamente en cualquier lugar del planeta sin movernos de casa.
De hecho esas técnicas ya ni siquiera pueden calificarse de novedosas. Son las que han difundido la computadora fuera de los ámbitos específicos de la profesión y la han convertido en una herramienta de uso común para cualquiera, al permitir una complejización del software inimaginada hace un par de décadas.
¿Y si de repente nos diésemos cuenta de que aquellas teorías sobre las que descansa nuestra forma de pensar el desarrollo de software en realidad son producto de una mirada obsoleta sobre la tecnología y nuestras propias capacidades? ¿Y si este gráfico estuviese al alcance de nuestras manos?
Termino con algunas preguntas: si pudiesemos cambiar el rumbo del desarrollo de un sistema a medida que avanza sin costos exorbitantes, ¿cómo desarrollaríamos? ¿qué factores tendríamos en cuenta en nuestras decisiones? ¿cómo diseñaríamos?
Hasta la segunda parte.
Actualización: segunda parte.
No hay comentarios.:
Publicar un comentario