Kent Beck sobre TDD, Estimados y Facebook


(David Lay) #1

Kent Beck, otro de los grandes en el desarrollo de software ágil, habla un poco sobre los aprendizajes que ha tenido en facebook, y como TDD no siempre es aplicacable, o como aveces incluso perjudica. También habla sobre como trabajar con estimados o como trabajar sin estimados.

Me llamó la atención que Kent haya hecho una reflexión tan profunda de su estadía en facebook, siento que ha llegado a un entendimiento mucho más profundo de que significa el desarrollo de software.


(Guillermo Schwarz) #2

No he visto el video, se me queda pegado, pero no entiendo cómo el creador de XP puede llegar a la conclusión de que TDD no siempre es aplicable y perjudica.

Eso es como decir “quiero ser ágil, pero a veces me enamoro de las cartas Gantt”.

No sé si se volvió loco o simplemente lo hace como una manera de autodesprestigiarse.

Lo que tengo entendido es que culturas como Facebook aplican ideas como A/B Testing. En ese caso la prueba ejecuta en producción, directamente sobre el usuario, de modo que es más profundo el test que simplemente TDD. En ese caso obviamente no te interesa TDD, el resultado del A/B testing es mucho más importante y más completo.

Sin embargo, la idea fundamental de probarlo todo no se ha perdido, al contrario, se ha ampliado. He aplicado testing tanto a los requerimientos, a los diseños y hasta a la vida cotidiana como dicen los agilólogos y no sólo funciona, sino que funciona perfecto SINCE 1993… No creo que esté hablando en serio, debe ser sólo una broma… espero.


(Guillermo Schwarz) #3

Antes de que se me olvide… no sería la primera vez que se contradice.

Una de las primeras reglas que tenía XP era “no overtime”, cerca del año 2000. Después de un año, si mal no recuerdo, la regla se cambió por “no more overtime than 2 hours per day during one week over a month”. De sólo leerla me da risa, porque sólo como suena es poco serio. Es como tratar de exprimir limones, te queda sólo con la cáscara seca en las manos. ¿Será por eso que se dice que están “dando jugo”?

Eso muestra que se vendieron… y lo malo del asunto es que una vez que creas reglas y las rompes, pierdes credibilidad, agotas a tu equipo de trabajo, y de ahí en adelante todo se viene cuesta abajo, porque ¿cómo recuperas a tu equipo si no les das tiempo libre? ¿De qué te sirve tener zombies en tu equipo con los ojos abiertos pero la mente dormida?

Pasó un par de meses y XP perdió popularidad frente a Scrum.


(David Lay) #4

Ese era uno de los motivos, otro, sobre la generación de un MVP desechable o en los spikes, si no mal recuerdo, pero el núcleo es sobre lo que mencionas, sobre cómo el FB el TDD no se practicaba cuando llegó a trabajar ahí y como en el tiempo se tuvo que dar cuenta que eso no era malo, ya que el feedback lo obtenían igual, casi tan rápido como en TDD.

Creo que hay valor en contradecirse, siempre y cuando sea debido a que ahora entiendes mejor el tema, pero concuerdo sobre lo del overtime, un poco conveniente aquello.


(Guillermo Schwarz) #5

Ya vi el video… Primero que nada recuerdo a Kent como alguien joven y ahora veo un abuelito, espero no verme así… ;-(

Una referencia a KKK… ¿es broma?.. That is so wrong… I don’t know what to say…

Así que cultivaba su propia comida… hay un término que se llama “red neck” que no es muy bonita para describir a la gente que vive en el campo.

My day job is to mentor… ¿¿¿???.. Really? … So no real programming experience inside Facebook???

Bueno si programan en C++ ya me imagino el enredo que hay ahí… Mi primer trabajo fue en C++ así que creo que tengo algo de autoridad en el tema, llegué a trabajar 7 años en el maldito lenguaje… Y aunque lo pasé bien, porque el lenguaje es como un animal que hay que montar y domar, tuve pesadillas hasta que inventé unit testing… Bueno creo que lo reinventé, porque al parecer la técnica viene de los años 50’s…

Por cierto esto no significa que los proyectos que hice fueran un fracaso, por el contrario, pero el problema real es que C++ en vez de ser una ayuda, era algo contra lo que había que luchar… demasiadas reglas para evitar sus pitfalls.

Tengo entendido que en Facobook puedes programar en el lenguaje que quieras y tienen una biblioteca o framework que permite interactuar con cualquier lenguaje…

You can’t write the test first… but why can’t you write them after?.. It makes no sense to me.

How fast can you learn from that cycle? … Tiene sentido si estás usando A/B Testing y luego haciendo revert si no funciona tu nueva página (ya que el objetivo de Facebook es que los usuarios entren a Facebook y se mantengan ahí, es decir, horas conectado al día, ese es el objetivo)… ¿cómo harías TDD con ese objetivo?.. No tiene sentido, pero A/B Testing es justo lo que necesitas.

Aunque simpáticamente no menciona A/B Testing, al parecer es un secreto de Facebook…

Kanban is about wearing the Kanban T-shirt? That is kind of offensive…

“Culture takes 10 or 20 years to change”… que buena frase.

Facebook is very individualistic… y les funciona, pero según Kent tienen que contratar gente que haga muchas preguntas, porque la información no está abierta ni publicada. Justo lo contrario de Agile… No sé si esta charla sería una buena idea respecto a tomarlo como ejemplo a seguir.

Para terminar:


(Guillermo Schwarz) #6

creo que realmente el problema de TDD es que los programadores se centran demasiado en la técnica y no en lo que quieren probar:

Este video tiene una opinión crítica de hacer TDD sin pensar en cómo se va a usar la clase, más que ciegamente seguir eso de “un test falla, lo corrijo” que en realidad es una segunda derivada, cuando el uso de la clase está claro, prefiero que el test se caiga para verificar que estoy probando algo, pero lo importante realmente es que estoy probando la funcionalidad de la clase.