XP, TDD y vibe coding: traducción de partes de la entrevista de Kent Beck con Programmatic Engineer

• Resumen de varias partes de la entrevista de Kent Beck, padre de XP y TDD, en Programnatic Engineer que me parecieron especialmente impactantes
• Si les gusta Kent Beck, recomiendo ver el video completo

---

P. ¿Cuál es el núcleo de XP?

Consiste en realizar estas 4 actividades.

1. Entender qué hay que hacer
2. Entender la estructura que nos permite hacer el punto 1
3. Implementar el punto 1 usando el punto 2
4. Verificar que el punto 3 funcione como se esperaba

Eso es todo. Y dividir el tiempo en partes muy pequeñas para que, en cada momento, hagamos un poco de las cuatro actividades, pero todas.

P. Entonces, ¿pair programming no es obligatorio en XP?

Cuando dirigía por primera vez un equipo XP, hacíamos despliegues cada 3 semanas y, por supuesto, había bugs.

Analizamos los patrones de los bugs que se encontraban después del despliegue, y resultó que todos provenían de código desarrollado en solitario. Dicho al revés: en el código desarrollado en pareja no hubo defectos reportados en producción.

P. Entonces no es obligatorio, sino más bien algo que recomiendas fuertemente, ¿no?

Tampoco. Lo que digo es que hay que experimentar. Puedes seguir desarrollando como siempre, pero despierto.

¿Quieres obtener los beneficios del diseño continuo, la verificación continua, la implementación continua o la interacción continua con el cliente? ¿Y aun así no lo logras porque sigues haciendo las cosas como siempre? Entonces tienes que cambiar la forma de trabajar.

Si alguien viene y me dice: “Kent, yo no hago TDD”, yo respondo: “¿Y qué?”

Si estás satisfecho con la densidad de defectos en tu código actual y con el nivel de feedback sobre tus decisiones de diseño, no pasa nada. Pero si no lo estás, entonces prueba pair programming o TDD.

P. Ya que salió el tema, ¿por qué creaste TDD?

Soy una persona que se preocupa mucho y tiende a la ansiedad, y para mí programar era una fuente constante de ansiedad. ¿Qué olvidé? ¿Qué rompí?

Pero cuando desarrollo con TDD, esa ansiedad desaparece. ¿Ya no se me ocurre ningún caso de prueba que pueda fallar? Entonces puedo estar seguro de que mi programa funciona. ¿Aparece aunque sea un poco de ansiedad? Simplemente escribo el siguiente caso de prueba.

Claro, TDD también tiene muchas ventajas técnicas: reducir la densidad de defectos, obtener feedback más rápido sobre las decisiones de diseño, hacer evolucionar el diseño de la implementación, etc. Pero para mí, lo más importante es haberme liberado de la ansiedad que me producía programar, que la experiencia emocional de programar haya cambiado por completo. Esa es la razón por la que creé TDD.

P. ¿Qué opinas de la crítica de John Ousterhout de que con TDD no hay espacio para que entre un buen diseño?

(Nota del traductor: John Ousterhout es el autor del gran libro Philisophy of Software Design, y hace unos meses apareció en el podcast Programmatic Engineer mostrando una postura crítica frente a TDD)

Hay una parte que él entendió mal. Eso simplemente es el resultado de una decisión. Si tratas TDD solo como la repetición de Red-Green, entonces claro que ahí no hay espacio para el diseño.

Como practicante de TDD, yo siempre trabajo moviéndome entre distintos niveles de abstracción. Por ejemplo:

• Ahora estoy en estado Red. ¿Cómo debería implementar esto para hacer pasar el siguiente caso de prueba (Green)?
• Esto está difícil. ¿Por qué está difícil?
• ¿Cómo debería cambiar el diseño para que la implementación necesaria para llegar a Green sea más fácil?
• ¿Cuándo debería introducir esa idea? ¿Ahora o después?
• Si la introduzco ahora, ¿hasta qué punto? ¿Solo un poco, lo mínimo que pueda hacer ya mismo, o en un chunk más grande?

Es decir, antes de escribir la prueba, siempre tengo un momento de diseño.

Antes de implementar, tomo decisiones sobre la interfaz, creo una prueba Red y, como no me gusta estar en Red, paso a Green lo más rápido posible. Una vez que estoy en Green, la ansiedad desaparece por un momento y me da espacio para pensar. “Mmm, sí pasó, pero esto no va a funcionar para otros casos. Tengo que generalizar más la implementación.”

¿Estoy en Red? Lo llevo a Green. ¿Estoy en Green? Respiro y pienso. Ese es mi ciclo de TDD.

P. A veces la implementación me parece demasiado obvia, así que implemento primero y luego hago las pruebas Red-Green. ¿Qué opinas de eso?

Probablemente es porque estás asumiendo que “esta forma de implementar es la correcta”, y mientras más correcta sea esa suposición, naturalmente menos beneficios tendrá escribir primero las pruebas.

Pero yo siempre pienso así: “Voy a seguir aprendiendo y acumulando experiencia, y este es el momento en el que menos sé.”

Es decir, asumo que voy a seguir aprendiendo y que la situación va a cambiar. Cuanto más tenga que aprender y más cambie la situación, más quiero postergar las decisiones tanto como sea posible. Es un principio general. Da igual si estás saliendo con alguien o cocinando.

Si puedes predecir más, puedes dar saltos más grandes. Pero el momento que más amo al programar es cuando voy avanzando convencido de que ya entiendo todo y de repente descubro que había una forma muchísimo mejor de implementar algo. Quiero vivir ese momento lo más seguido posible. Por eso hago TDD.

Si tienes muy clara la imagen en tu cabeza y puedes estar seguro de qué entrada producirá qué salida, entonces simplemente implementa. Pero cuanto más te equivoques, más aprendas y más impredecible se vuelva el mundo, más te conviene no comprometerte ahora y dejarlo para después.

P. ¿Sigues desarrollando con TDD como antes incluso cuando programas con AI?

No es fácil responderlo de manera simple.

Yo uso las pruebas como medio de comunicación con la AI, sobre todo como una forma de decirle qué hizo mal. Este tipo intenta borrar y modificar mis pruebas todo el tiempo, y cada vez que lo hace lo regaño. Mis pruebas están bien, así que hazlo correctamente.

La AI muchas veces toma decisiones malas a largo plazo. También se le da realmente mal bajar el acoplamiento y subir la cohesión. A veces, si le dices con muchísima claridad qué tiene que hacer, lo logra, pero en general hay que asumir que no diseña bien.

Por eso preparo muchísimas pruebas. Las uso como un medio para detectar si la AI está rompiendo algo.

(Nota del traductor: para ver cómo usa Kent Beck TDD en vibe coding, consulta este texto)

P. Parece que si se popularizaran reglas para agentes como “nunca corrijas las pruebas” o “si no pasan las pruebas, sigue modificando solo el código de implementación hasta que pasen”, todo sería más cómodo. También da la impresión de que estamos redescubriendo cosas que eran importantes en los 2000. ¿Qué opinas?

Hay que seguir experimentando. Hay que probar todo lo posible. Porque no sabemos qué es realmente lo mejor en este momento.

El horizonte de lo que es “barato” y lo que es “caro” cambió por completo. Muchas cosas que antes no hacíamos porque parecían costosas o difíciles ahora se volvieron ridículamente baratas.

Si de un día para otro los autos se volvieran gratis, ¿qué crees que pasaría? Obviamente algo cambiaría, pero ¿qué cambios secundarios y terciarios surgirían a partir de eso? Nadie puede predecirlo. Así que por ahora no queda más que probar muchas cosas.

P. Dijiste que, aunque llevas más de 50 años programando, ahora te estás divirtiendo más que nunca. ¿Qué quieres decir con eso?

Se volvió más fácil que nunca hacer realidad mis grandes ideas. Ver si la AI puede implementar esa idea, observar cómo lo hace y ajustar el rumbo es increíblemente adictivo. Como nunca sabes bien cuándo va a salir bien, y cuando sale bien como por magia se siente glorioso, se parece a una tragamonedas. Antes de irme a caminar o a almorzar, siempre me tienta dejarle aunque sea un prompt más para que siga trabajando.

Hace dos años dejé este tuit: “Sentía resistencia a usar ChatGPT, y hoy entendí por qué. El 90% de las habilidades que tengo ahora valen $0. Y el 10% restante aumentó 1000 veces. Llegó la hora de recalibrar mis habilidades.”

> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023

(Nota del traductor: cuando ese tuit se volvió tema de conversación, Kent también dejó un texto un poco más largo.)

En ese momento dijo que todavía estaba explorando qué era ese 90% y qué era ese 10%, pero ahora ya puede responderlo hasta cierto punto. Tener una visión audaz, poder establecer hitos hacia esa visión y seguir avanzando mientras ajustas el diseño y mantienes la complejidad bajo control. Esa es una habilidad muchísimo más importante que conocer la sintaxis de un lenguaje específico (por ejemplo, saber dónde poner &, *, [ en Rust).