Programadores como jardineros

Hace tiempo leí un interesante artículo del músico Brian Eno titulado “Composers as Gardeners” (Compositores como jardineros).

La idea básica de Eno es darle la vuelta a la manera de componer música, pasando de un proceso en el que el compositor diseña todos los detalles de la pieza a priori, a uno en el que le da un pequeño empujón inicial y la deja evolucionar como si tuviera vida propia. En palabras del propio Eno:

[…] había asumido que la música se producía o se creaba de la misma manera que imaginamos la composición de sinfonías, es decir, como un proceso en el que se tiene una idea completa y detallada de una obra, que después se pone de alguna forma en el papel para que otros puedan reproducirla. Es también así como imaginamos el trabajo de un arquitecto: primero diseña el edificio, con todos sus pormenores, y luego lo construye. […] un nuevo paradigma de composición: cambiar la imagen del compositor como una persona que se para en lo más alto del proceso y dicta con precisión cómo debe llevarse a cabo, por la de alguien que está en lo más bajo y que lo único que hace es plantar semillas bien seleccionadas –con suerte– y mirar cómo se convierten en algo.

Esta idea se me quedó grabada en la cabeza y ahora, al practicar el Desarrollo guiado por pruebas, ha vuelto al primer plano para indicarme que está técnica de programación encaja con la filosofía de Eno.

Arquitectos

Cuando desarrollamos las pruebas unitarias después del programa principal (si es que se llegan a desarrollar) somos como el compositor situado en lo más alto del proceso. Esto nos obliga a tener una visión global y precisa de lo que queremos construir. Esta idea (heredera del nefasto y hasta hace poco omnipresente intento de asemejar el desarrollo de software a otras ingenierías) es poco realista y acaba generando sistemas enrevesados, rígidos y frágiles.

Jardineros

Sin embargo, si seguimos la técnica TDD, nos convertimos en ese jardinero que planta las semillas y va observando el crecimiento de las mismas, regando o abonando cuando es necesario.

Solo creamos una clase cuando la prueba nos la pide (error de compilación), solo codificamos un método cuando es necesario para hacer pasar una prueba que antes había fallado.

Los detalles del diseño del programa (del cual antes de empezar solo teníamos una idea global) van surgiendo prueba a prueba igual que los brotes de una planta. Y este diseño es el más natural y orgánico, ya que ha surgido de lo que demanda en cada momento el sistema.

Otras personas han encontrado antes conveniente la metáfora entre jardinería y desarrollo de software:

Programming is Gardening, not Engineering
A Conversation with Andy Hunt and Dave Thomas, Part VII
by Bill Venners
You are NOT an engineer!
Software Gardening Manifesto

Así pues voy a intentar parecerme cada vez más a un jardinero y no a un arquitecto. Como dice el propio Eno son, como mínimo, iguales en dignidad.

P.D: Este artículo ha sido escrito escuchando continuamente Discreet Music.