Mira al mago. Mira cómo deja caer una moneda en su mano, cierra su mano, te muestra la mano cerrada, la abre con una floritura, y la moneda desaparece. Él sonríe. Miras a su otra mano. Lo da vuelta y lo abre con la misma floritura. ¡Allí tampoco! Luego toma tu mano, la cierra en un puño, la abre y ahí está la moneda.
Ahora mira de nuevo. Esta vez mira la otra mano. Al girar la mano superior y cerrar el puño, la moneda se desliza hacia la mano inferior en un movimiento mucho más pequeño. Abre la mano vacía y mueve la mano inferior hacia arriba. Ignore el movimiento obvio. En vez de eso, note cómo guía la moneda entre sus dedos medios. Ignore cómo abre la otra mano y en su lugar véalo caer discretamente la moneda en la primera mano de nuevo. Por último, sienta cómo se desliza la moneda en la palma de su mano mientras cierra los dedos. ¿Magia? Tal vez no. Sino una ilusión clásica.
La magia funciona por desorientación. El mago se aprovecha de tu tendencia a mirar lo obvio mientras la acción real tiene lugar en otro lugar. Cuando lo obvio se hace lo suficientemente convincente, es difícil siquiera imaginar mirar hacia otro lado. Los economistas tienen un nombre para el impacto de buscar en un solo lugar: lo llaman Costo de Oportunidad. Lo que sea que estés haciendo en este momento viene a costa de todo lo demás que puedas estar haciendo en su lugar, y siempre hay otras cosas que podrías estar haciendo. Pero no estás considerando las otras cosas porque estás ocupado concentrándote en lo obvio.
¿Cómo se aplica esto a las prácticas de desarrollo de software? Por lo general, una nueva práctica comienza como un consejo bien intencionado: "Probamos esta cosa[stand-ups, programación de pares, TDD, gráficos de quemado, iteraciones, automatización de la construcción] y funcionó bien para nosotros. Tal vez deberías intentarlo tú también!"
Demasiado pronto hay una agenda adjunta: "Lo intentamos y creemos que podemos ganar dinero enseñando a la gente cómo hacerlo. Deberías usarlo porque funciona! Aquí hay un libro blanco que lo prueba."
Por cierto, si lees esa lista de prácticas y piensas "pero todas esas son buenas cosas que hacer", te estoy hablando. ¿Dónde no funciona la técnica? ¿Qué más podrías estar haciendo en su lugar? ¿Cuáles son las ventajas y desventajas de elegir esto en lugar de una de las alternativas?
Durante los últimos dos años he estado trabajando con equipos que eran más productivos que todo lo que había visto antes. Sus métodos eran una mezcla de técnicas ágiles "tradicionales" y prácticas locas y contra-intuitivas que me dieron un choque cultural. Tuve que desaprender un montón de sabiduría recibida antes de poder empezar a pensar de la manera en que ellos lo hicieron.
Pruebe este ejercicio de dos partes: Piensa en una práctica o técnica que utilizas cuando desarrollas software, tal vez tu práctica favorita. ¿Entendido? Ok, parte 1: ¿por qué lo haces? ¿Qué beneficios le proporciona? Probablemente puedas pensar en unos cuantos. Escríbalas. Ahora, parte 2: ¿dónde no lo usarías, y cuáles son algunas alternativas? Anote algunos pros y contras de cada uno. Esperaré.
Lo más probable es que encuentres esa segunda parte mucho más difícil. Si la mayoría de las veces se le ocurrieron razones negativas o irónicas para las alternativas, sólo está enumerando más razones para usar la práctica original. No se puede ver más allá de las alternativas. ¡Has sido engañado!
A modo de ejemplo, me voy a referir a la TDD, ya que es una de las prácticas más dogmáticamente defendidas que he encontrado, pero se puede aplicar este enfoque a cualquier cosa. Vamos a ver el TDD -realmente míralo- y ver si podemos descubrir dónde brilla y dónde no es tan útil.
Si usted es un usuario de TDD, tómese un momento para pensar en dónde no lo usaría y qué podría hacer en su lugar. Recientemente he visto a un par de personas preguntando esto como un reto retórico o incluso irónico, como si estuvieras loco si alguna vez consideraras no usar TDD.
Los defensores de la TDD dicen cosas como "La TDD te permite hacer cambios constantes y seguros". A menudo lo hace. "TDD permite un diseño emergente." Tal vez. "Las pruebas automatizadas actúan como una suite de regresión y detienen la reintroducción de errores". A menudo lo hacen. "Las pruebas actúan como documentación viviente". Ellos pueden. "El software basado en pruebas es más limpio y fácil de cambiar que el no basado en pruebas". En realidad, no estoy de acuerdo con ésta. He visto impactantes bases de código de TDD puro, y bases de código limpias y habitables sin pruebas automatizadas en absoluto.
Echemos un vistazo al costo de oportunidad -las compensaciones- en cada una de estas afirmaciones. Cada uno podría ser un artículo en sí mismo. Sólo quiero darte una idea de cómo encontrar las ventajas y desventajas inherentes a este tipo de declaraciones.
¿Qué es lo que no le gusta del cambio constante y seguro? Bueno, a veces se puede describir el problema pero no se puede ver una respuesta obvia. Las aplicaciones de operaciones financieras son muy parecidas a ésta: puede probar varios enfoques y ver cómo funcionan, como una serie de experimentos. Usted quiere que cada experimento sea barato para que pueda probar varios. La TDD de cada opción funcionará, seguro, pero va a ser más costoso que simplemente esbozar algo para ver si se siente bien.
¿Cuál es el costo de oportunidad de todo ese tiempo extra dedicado al TDD de los bocetos? Usted puede dibujar media docena de ideas en el tiempo que le tomaría a TDD cualquiera de ellas. Y no termina ahí. El resultado de un intento puede cambiar su comprensión del problema tanto como ofrecer una solución potencial, lo que le envía en una nueva e inesperada dirección. Algunos defensores de la TDD dirán que se trata de una serie de picos y que no es necesario que los tenga. Sin embargo, estoy hablando de poner el software completamente en producción, y mantener los experimentos exitosos como software de producción, así que esto realmente no se sostiene.
El test de diseño (DDT) bloquea su suposición sobre el objetivo final deseado. Asume que sabes hacia dónde te diriges, o al menos desde dónde empiezas. Si usted no sabe cuál es la solución, esto podría ser una estrategia indeseable. Tal vez debería posponer la inversión en una solución hasta que sepa más sobre el problema.
A veces el diseño correcto no te mira a la cara. Podría ser necesario un cambio de perspectiva, una reevaluación de toda la premisa, para ver la simplicidad a través de la aparente complejidad. El DDT se trata de un cambio y una mejora incrementales. Es ideal para encontrar máximos locales, pero la mejor solución podría requerir un replanteamiento radical. El costo de oportunidad en este caso es que nos quedamos atrapados en este máximo local y nos perdemos una victoria mayor. En términos esbeltos, esta es la diferencia entre el Kaizen, la mejora continua, y el Kaikaku, la transformación abrupta. Ninguno de los dos puede tener éxito sin el otro, pero hemos tendido a centrarnos sólo en los Kaizen como una forma de optimización.
TDD es el epítome de la programación Kaizen. Para brillar necesita un ambiente en el que puedas dar un paso atrás, dar un paseo mental alrededor de la manzana, volver y tal vez cambiarlo todo. Se necesita una visión global, un diseño o una arquitectura de "imagen global". TDD no te dará eso. Sin embargo, una aplicación robusta de comportamientos complejos se beneficiará del enfoque incremental que proporciona la DDT. Notarás que no estoy sugiriendo no usar TDD sino calificar dónde y cómo es efectivo.
No escribes software porque quieras software, escribes software para proporcionar una capacidad. En varias aplicaciones recientes llegamos a un punto en el que reescribimos el sistema para añadir una nueva capacidad. Suena precipitado, no importa el despilfarro, pero lo que habíamos aprendido al llegar a donde nos dijeron que sería más efectivo reescribir -a menudo en una tecnología diferente- el subconjunto de la aplicación que contenía el valor real. Un sistema comenzó en Scala y se movió, en trozos, a Java (¡en la dirección equivocada, seguramente!). Otro comenzó en Python y se movió a JavaScript y node.js. Otra empezó en Python y fue reescrita en otra aplicación de Python! Cada reescritura era el resultado de conseguir el software delante de la gente, de la gente de las operaciones así como de los usuarios, y de responder a su regeneración. En ese contexto no importaba cuán hecho a mano o probado el código original, porque tirábamos la mayor parte de él.
No habíamos invertido demasiado en el software al rodearlo con pruebas automatizadas exhaustivas, de lo contrario habría sido un ejercicio costoso. ¿Pero qué hay del software que sobrevivió? Encontramos que era posible producir niveles de calidad TDD después del hecho. Sabemos cómo es un software bien hecho, y a estas alturas ya sabíamos que estábamos dispuestos a invertir en él: había demostrado su valor. Así que empezamos a introducir pruebas de tipo TDD para las partes más complejas o críticas del código, lo que nos llevó a refactorizarlo para hacerlo más testeable, lo que creó costuras y subsistemas naturales en el código, dando lugar a refactorizaciones más grandes, etc. He estado describiendo esta técnica como Spike and Stabilize: conseguir algo, cualquier cosa, en la producción para solicitar retroalimentación rápida, e invertir en lo que sobreviva.
Las pruebas automatizadas proporcionan la seguridad de que el código está haciendo lo que debería. Esto sugiere dos preguntas: ¿Existen otras formas de obtener esa seguridad? ¿Y la garantía es valiosa?
Las pruebas automatizadas son buenas para ejercitar piezas de código específicas. ¿Encontrarías errores en ese código sin las pruebas? No puede evitar notar que falta un botón de envío o que no está conectado. Si la aplicación falla en la mitad de la recuperación de datos, ¿qué debe hacer? Una vez que lo has codificado para hacer eso, ¿es probable que deje de hacerlo? ¿Una prueba automatizada le dará más seguridad? ¿Qué podrías hacer en su lugar?
El valor de una prueba automatizada depende de una serie de factores: la criticidad del código, el impacto de una cosa mala que ocurre, el coste de corregir esa cosa mala, que puede ser tanto reputacional como operativa, la probabilidad de que no la descubras con un uso regular en el desarrollo, tu familiaridad con el dominio. El código en los bordes de un sistema es a menudo más difícil de probar que el código interno. La automatización de widgets de interfaz, puntos de integración externos y servicios de terceros puede resultar costosa. ¿El costo justifica el valor? Una vez más, no digo que no lo hagamos, sino que cuestionemos las compensaciones y decidamos dónde tiene sentido. He visto a los equipos quemar semanas de esfuerzo de desarrollo creando hermosas suites de pruebas automatizadas que casi no proporcionaban ninguna garantía adicional o retroalimentación sobre el uso de la aplicación. El costo de su reputación es alto: pierden credibilidad ante las partes interesadas, que prefieren que se les entreguen las características. Una vez más, es necesario encontrar un equilibrio, entendiendo dónde la automatización es valiosa y dónde es un hábito.
Hay muchos tipos de documentación. La documentación valiosa lo educa a usted. Te dice cosas que de otra manera no sabrías porque no son obvias. Usted quiere saber qué hace que este sistema sea diferente de todos los demás sistemas similares que ha visto. (Usted también puede preguntarse por qué está documentando estas rarezas, en lugar de eliminarlas del sistema y reducir el nivel de sorpresa para un recién llegado, pero esa es otra historia).
Algunas pruebas automatizadas se parecen más a documentos históricos, lo que da una idea de los tiempos pasados. Tal vez en un momento dado hubo un error tonto en el que refrescar el estado actual disparó un correo electrónico a la oficina. Lo descubrieron de inmediato, por supuesto, así que los desarrolladores escribieron una prueba llamada "no debería enviar correo electrónico a la oficina cuando se actualiza el estado actual". ¿Qué? Por supuesto que no debería. Pero con el tiempo acumulamos muchas de estas pruebas "por supuesto que no", aumentando el ruido entre la señal, por lo que se hace más difícil encontrar la documentación viva realmente útil. Vivir no es sinónimo de ser útil. La curaduría de documentación viva -pruebas automatizadas- es una actividad tan importante como la curaduría de cualquier otro tipo de documentación. Con demasiada frecuencia se pasa por alto.
Aunque me he centrado en la TDD en este artículo, hay un valor en identificar el costo de oportunidad y las compensaciones a través de todas sus prácticas y actividades. Considero que la DDT es una técnica de desarrollo valiosa e importante, pero hay contextos en los que brilla y otros en los que es un obstáculo. Así que no tome nada en serio y busque las compensaciones en cada decisión que tome, porque esas compensaciones están ahí, las vea o no. Y si puedes aprender a verlos, puedes hacer magia.