La herejía de Kent Beck
Hace unos días sucedió algo que escandalizó al pequeño mundo del desarrollo de software con metodología XP.
Si usted conoce de metodologías ágiles, el nombre de Kent Beck seguro le dice mucho. Kent fue el creador de lo que conocemos ahora como Extreme Programming o XP, una metodología de desarrollo de software inscrita en el contexto ágil y una de las más agresivas en cuanto a velocidad se refiere. La metodología XP, como cualquier conjunto de lineamentos de cómo se hacen las cosas, tiene muchas recetas que “deben” seguirse a pies juntillas, por ejemplo: programar en parejas, refactoring continuo, y desarrollo dirigido por pruebas (Test Driven Development TDD).
El TDD exige que los programadores no escriban código de funcionalidad si antes no han escrito pruebas unitarias que validen el código que se escribirá. La idea es bastante directa: De un requerimiento funcional obtenemos una responsabilidad atómica del actor (clasificador, clase, etc.) que estamos modificando o creando, basados en esta responsabilidad escribimos el código que usaría esta funcionalidad, un código que además evalúa que la funcionalidad en cuestión haga lo que tiene que hacer. Éste código es la prueba unitaria, que funciona como documentación y ejemplo de código. Con la prueba unitaria programada, ahora tenemos que escribir el código para que la prueba tenga sentido semántico, o para que compile, en términos más directos. Cuando el código compila, podemos pasar a la parte en la que programamos lo necesario para pasar la prueba, y según el TDD, sólo debemos programar el código necesario para pasar la prueba. Si nos damos cuenta de que nuestra prueba no es suficiente para garantizar la funcionalidad que queremos, hacemos otra prueba y repetimos el proceso. De esta manera obtenemos un código probado que sólo hace lo que tiene que hacer -recordemos el viejo principio de que el código que nunca falla es el código que nunca se escribió.
Pues resulta que Kent Beck, como todo gurú, como cualquier padre de familia incluso, no parece tener el derecho de decir que a veces es posible, incluso aceptable, no seguir las reglas que él mismo escribió. En su blog personal, Kent escribió, aunque para muchos parece más bien que confesó, había escrito parte del código de JUnit Max sin escribir pruebas; o sea, que escribió a capela y sin paracaídas, lo cual, acá entre nos, es algo que hacemos todos los partidarios de la XP y del TDD, aunque no todos se atreven a reconocerlo.
El problema que yo veo en las exaltadas manifestaciones de rechazo a la publicación de Kent no es que el gran gurú se nos esté rajando, que no es el caso, sino que los partidarios de las metodologías convierten a estas en verdaderas ideologías fundamentalistas que derivan en fanatismos como los que observamos en las religiones y los nacionalismos. Una metodología no debiera ser nunca inflexible, o dogmática, mucho menos si se supone que es “ágil”, sin embargo, parece que los partidarios de la XP son tan susceptibles al fanatismo como lo fueron los lúmpenes al nazismo.
Las razones para no seguir a ojos cerrados el TDD pueden ser muchas, las razones para volverse un recalcitrante fanático de la XP no existen. Y lo que pasó con la XP y Beck no es muy diferente de lo que ha pasado con tantas y tantas ideas convertidas en manuales de Carreño por la falta de criterio de sus seguidores. Me atrevo a pensar que fue lo mismo que pasó con muchas religiones, con la aclaración de que en las religiones fue el fanatismo el que le ganó a las ideas.



Hola, good post, but let me clarify something:
You said: Kent escribió…había escrito parte del código de JUnit sin escribir pruebas
He did not. JUnit was and is developed test-first because JUnit is a long-game. It is JUnit Max that is sometimes not developed test-first, because it is a short game
In his words:
“JUnit is a long game/b–lots of users, stable revenue ($0, alas), bounded scope”
“Working on JUnit, the whole bag of XP practices makes sense. We always test-drive development. ”
“With JUnit Max I am living the short game of software.”
“When I started Max I didn’t have any automated tests for the first month. I did all of my testing manually. ”
“Whether or not to write automated tests requires balancing a range of factors. Even in Max I write a fair number of tests.”
“When working on Max, the question of whether or not to write a test boils down to whether a test helps me validate more experiments per unit time. It does, I write it.”
Thank you Philip, your clarification is important. The project in this affair was in fact JUnit Max that is not the same as JUnit. I have fixed the references in the post.
wigahluk: me quedé en China, no entendí nada, ahora me pones a correr porque quiero entender, así que buscaré a mi hijo que sí sabe de esto y que me traduzca lo que has escrito. Perdona mi ignorancia, pero quiero seguirte y si has escrito esto, importante debe ser.
Saludos,
AD.
Adela, con tu comentario me doy cuenta de que he escrito este post como programador y para programadores.
No es tan importante entender los detalles, lo que quería decir es que a veces pasa, no importa que tan flexible o culta se supone que sea una comunidad, que alguien inventa una forma de hacer las cosas que funciona bien y que después llegan otros y convierten esa forma en algo muy parecido a una religión, algo que debe hacerse sin pensar.
Me pareció extraño que eso sucediera justamente con una comunidad (la de los programadores con metodología XP) que presume de ser muy flexible y tolerante.
Tampoco digo que todos los partidarios de la XP sean unos fanáticos de panfleto, más bien han sido pocos los que criticaron a Kent y muchos los que lo defendimos, pero esos pocos fueron suficientes para recordarme que el fanatismo es parte de la naturaleza humana.