Arregla como si nadie estuviera viendo

Hay una deuda técnica que se percibe a simple vista.

Una estructura de datos inadecuada puede conducir a un código enrevesado. Cuando los requerimientos cambian continuamente, el código puede contener trazas de enfoques anteriores. En ocasiones, el código se escribe de prisa o simplemente con descuido.

Este tipo de deuda técnica es fácil de analizar porque se percibe con claridad. Se manifiesta en forma de errores, problemas de rendimiento y dificultades para añadir nuevas características.

Sin embargo, hay otra forma más maliciosa de deuda técnica.

Quizá las pruebas corren algo lento. No lento como una tortuga, pero sí lo suficiente para que no te preocupes en echarle una ojeada a los errores y, en cambio, lo añadas a tu lista de tareas pendientes. Tal vez no confías en el script de despliegue y omites el lanzamiento de una nueva versión. Quizá las capas de abstracción hacen que sea demasiado difícil localizar una baja en el rendimiento, así que dejas un TODO en el código. A veces, las pruebas unitarias son demasiado rígidas y pospones el intento de una nueva e intrigante idea hasta después que hayas entregado las características planeadas.

Nada de esto es un factor decisivo. En todo caso, podrían parecer distracciones. Parece en vano quejarse. Después de todo, si en verdad importaran, habrías completado estas tareas a pesar de la fricción, ¿cierto?

Y por tanto ninguna de ellas termina por hacerse. No parecen lo suficientemente importantes por sí mismas. La fricción las mató. Algunas de esas exploraciones podrían no tener consecuencia alguna. Otras podrían redefinir tu proyecto.

Nunca sabes cuál es cuál. Es por eso que debes reducir la fricción de forma constante. Como si el destino de tu proyecto dependiera de ello. Porque lo hace.

Arregla como si nadie estuviera viendo.