Por: Iván Jiménez
En diversos proyectos donde he participado, con el rol de programador y hasta Agente de Cambio, me ha tocado interactuar de diversas formas con la deuda técnica.
Y es que, es muy fácil trabajar al estilo Cowboy sin asumir las consecuencias de las malas prácticas al trabajar.
Momento de analogía culinaria: imagina que vas a preparar una receta, por primera vez.
Estas deseoso por preparar esa receta y quedar bien con esa persona especial, con los amigos, con los papás… Te arrancas sin preparar tu ambiente en el cual vas a combinar ingredientes, batir, etc.
Inicias sin validar que los ingredientes que compraste los tenías a la mano.
¿Qué ocurre?
Haces un batidillo, casi te tropiezas y tiras tu mezcla, te das cuenta de que te faltaron ingredientes y los sustituyes por otros.
Al final, puede pasar que el plato que querías preparar no saliera como quisiste, quedando algo diferente, malo o definitivamente malo. Esto es deuda culinaria (me he percatado no existe el término así que hemos inventado un concepto).
La deuda técnica es una enfermedad que afecta a personas, proyectos y empresas. Es preocupante ver la poca preocupación por la excelencia técnica que hay en muchos lados.
Los síntomas típicos de esta enfermedad y/o frases típicas que se usan en este contexto son las siguientes:
- Inicio del desarrollo sin preocuparse mucho por la arquitectura (después lo corregimos, al fin que mientras haga lo que el cliente pide es suficiente, ¿o no?)
- Desarrollo sin saber si ocuparemos patrones, frameworks o programación “pura” (después le cambiamos el nombre a las variables, cada uno hágalo como pueda y después lo integramos)
- Ausencia de pruebas unitarias (¿dudas de la calidad de mi código? ¿Me estás diciendo mal hecho?)
- Falta de colaboración con las personas responsables (¿para qué integro a pruebas? ¿El usuario? Nah, ese hasta el final se entera de lo que hicimos)
- Entreguemos ya… no es necesario que hagamos pruebas de integración o regresión… eso es muy de los 2000
- No hay tiempo para dejar los ambientes homogéneos, adáptale… al fin que, la adaptación es agilidad, ¿o no?
Y es que es tan común este tipo de cosas que ya se vuelve parte de nuestro folklore del conformismo.
Típicamente el homínido que adopta y asimila esta enfermedad pierde noción de la innovación, entra en una condición de “conformismo reptiliano” que lo lleva a su versión más básica y primitiva.
¿Oiga doctor, y esto tiene cura?
En muchos casos, si. Se trata de asumir un compromiso responsable de la calidad de la comunicación, de las interacciones, de preparar adecuadamente lo necesario para el arranque o mantenimiento de un proyecto.
Se trata de no iniciar si no tenemos claro que tenemos que hacer. De Sprint con Sprint asegurar la alta calidad técnica que la persona está haciendo, y de ser un cómplice positivo del equipo para que todos lo asuman.
De no hacerse el “ciego” cuando hay porquerías en el código. Levantar la mano humildemente y decir “bueno, esto de acá está mal, no es mío, pero no importa… no pretendo cazar al culpable… yo lo corrijo y lo dejaré según los más altos estándares que tenemos y que conozco”
Es preferible entregar tarde que entregar cosas mal. Validar si el pedazo de trabajo que se acaba de hacer es digno del repositorio. Validar si eso llena de orgullo al artista que lo hizo… y si no, hay que hacer algo.
Dedicarle unos minutos más antes de querer salir corriendo de la oficina, asegurándose que lo que hizo la persona es software increíble, y no un pedazo inerte contaminado de bichos.
Sacudirse esa pereza mental y espiritual que mantiene al Developer en su círculo de comodidad apestoso y gris.
Rompamos, por amor al arte de hacer software, esa maldita comodidad de hacer las cosas a medias. Seamos muy estrictos con nosotros mismos. Dejemos de repartir culpas y encontrarle justificación a lo mal que en ocasiones hagamos el trabajo. Asumamos la responsabilidad de hacer proyectos geniales, por fuera y por dentro.
Yo le recomiendo, querido lector, que valide si en su vida no tiene algún tipo de deuda: culinaria, emocional, del oficio, con el SAT (estas son igual o más peligrosas que la deuda técnica).
Si es así, es el principal responsable de corregirla. Sea usted el cambio, no espere que los demás lo hagan.
Asume la mentalidad de “parar la línea de producción” y revisar que hicimos algo mal, para que lo corrijamos como equipo y podamos proseguir.