Haz lo invisible más visible
Autor: Jon Jagger

Muchos aspectos de la invisibilidad son correctamente dichos como principios a usar. Nuestra terminología es rica en metáforas de invisibilidad, mecanismos de transparencia y ocultamiento de información, para mencionar sólo dos. El software y el proceso de desarrollo pueden ser, para parafrasear a Douglas Adams, casi invisibles:

• El código fuente no tiene una innata presencia o comportamiento, y no obedece las leyes de la física. Es visible cuando lo cargas en un editor, pero cierra el editor y se ha ido. Piensa sobre eso un rato y, como el árbol cayendo cuando nadie lo escucha, empieza a preguntarte si en realidad existe.
• Una aplicación en ejecución tiene presencia y comportamiento, pero no revela nada del código fuente con el que fue construido. La página principal de Google es placenteramente minimalista; lo que pasa detrás es lo realmente sustancial.
• Si has terminado el 90% y estás eternamente atorado tratando de debugear el último 10% entonces no has acabado el 90%, ¿o sí? Corregir errores no es progresar. No te pagan por debugear. El debugging es un derroche. Es bueno hacer una pérdida más visible así puedes ver qué es y empezar a pensar en no crearla, en primer lugar.
• Si tu proyecto está aparentemente en camino y una semana después está seis meses atrasado, tienes problemas, el más grande de ellos probablemente no sea que estás seis meses tarde, ¡sino que el campo de invisibilidad es lo suficientemente poderoso como para ocultar seis meses de retraso! La falta de progreso visible es sinónimo de la falta de progreso.

La invisibilidad puede ser peligrosa. Piensas más claramente cuando tienes algo concreto a qué amarrar tu pensamiento. Administras mejor las cosas cuando puedes verlas y verlas cambiar constantemente:

• Escribir pruebas unitarias provee evidencia sobre qué tan fácil es el código unitario con respecto a la prueba unitaria. Ayuda a revelar la presencia (o ausencia) de cualidades de desarrollo que te gustaría que el código exhiba; cualidades como bajo acoplamiento y alta cohesión.
• Ejecutar pruebas unitarias provee evidencia sobre el comportamiento del código. Ayuda a revelar la presencia (o ausencia) de cualidades en tiempo de ejecución que te gustaría que la aplicación exhiba; cualidades como la fortaleza y la correctitud.
• El usar tableros de boletines y tarjetas hace el progreso más visible y concreto. Las tareas pueden ser vistas como “No iniciadas”, “En progreso” o “Terminadas” sin la referencia a una herramienta de administración de proyectos y sin tener que perseguir a los programadores para que entreguen reportes de estatus ficticios.
• Realizar desarrollo incremental aumenta la visibilidad del progreso del desarrollo (o la falta de él) al incrementar la frecuencia de la evidencia del desarrollo. El completar la liberación del software revela realidad; los estimados no.

Es mejor desarrollar software con una gran cantidad de evidencia visible habitual. La visibilidad otorga confianza de que el progreso es genuino y no una ilusión, deliberado y no involuntario, repetible y no accidental.

Traducción: Espartaco Palma

Leer contribución original