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