El origen de la deuda técnica es una mezcla de distintos fenómenos en variadas proporciones:
- Herramientas obsoletas o en proceso de quedar obsoletas (entiéndase que ya no reciben nuevas actualizaciones).
- Bajos estándares de desarrollo.
- Problemas de liderazgo.
- Diseño deficiente.
- Tiempos de entrega mal calculados.
- Estrés.
- Poca experiencia del desarrollador.
- El simple paso del tiempo.
- Rotación en el equipo.
- Mezcla de tecnologías.
Y seguramente podríamos pensar en muchas más...
Todos en una empresa de tecnología pueden colaborar de una forma u otra en la creación de un ambiente propicio para la expansión descontrolada de la deuda técnica.
A pesar de que sea un fenómeno inevitable en el mundo del software, cada miembro del equipo puede, según su posición, contribuir significativamente a reducir la velocidad en que la deuda técnica crece, y a reducirla cuando sea propicio.
En mi experiencia estas son las principales acciones que pueden realizar los programadores, según su rol y experiencia, para intentar controlar la deuda técnica, y que no requieren un esfuerzo demasiado significativo:
Desarrolladores Trainee/Junior:
- Antes de comenzar a programar una tarea buscar entender el problema. Si la solución no es obvia entonces buscar de forma temprana la opinión general de alguien más senior. Esta búsqueda de opinión y consejo debe dejar explícito de que haz hecho una investigación previa significativa.
- Si en el proyecto en que trabajas existe más de una forma de solucionar parte de tu tarea pregunta a tu equipo cual es la preferible.
- Una vez que el código funciona y los tests están escritos el trabajo aún no termina: ahora es el momento de revisar con detalle tu trabajo, mejorar la legibilidad y estandarizar las prácticas en relación a las recomendaciones y usos de tu equipo.
- Nunca agregar nuevas librerías/herramientas sin antes consultar a alguien más senior.
- Usar bien el tiempo y comenzar tempranamente a desarrollar la feature: El apuro produce malos resultados.
Desarrolladores Semi-senior/Senior
- Siempre dejar el código en mejor estado de cómo lo encontraste
- Evitar abstracciones y soluciones complejas cuando sea posible.
- Aprender a decir "SI, PERO". Si tus manos ya están ocupadas en una feature y te piden comenzar otra, deja claro que la primera quedará en pausa y su fecha de entrega será atrasada, o cómo el aumento de carga puede perjudicar el resultado final.
- Al diseñar una nueva feature, siempre intentar ser lo más generalista posible, intentando prever nuevos requerimientos que puedan aparecer en el futuro, y no limitarse a satisfacer los requerimientos mínimos que están siendo solicitados. Esto no quiere decir que debemos programar de más, sino que nuestros diseños deben estár preparados para extenderse y cubrir nuevos casos sin grandes refactorizaciones. Por ejemplo si en nuestra aplicación nos piden que se puedan crear configuraciones para TODOS o para UN usuario, no olvidar que en el futuro nos podrían pedir crear una configuración para un GRUPO determinado de usuarios.
Líderes técnicos y similares
- Proteger al equipo de desarrollo frente al resto de la empresa. No permitir que los equipos de ventas/soporte/etc les hagan solicitudes si no es pasando por ti como intermediario.
- Procurar que la creación de test unitarios robustos sea una práctica requerida en el equipo, y que estos corran de manera automatizada al realizarse el pull request.
- Al momento de elegir nuevas herramientas y tecnologías es sano evitar soluciones muy novedosas. Siempre es más seguro elegir herramientas que, aunque parezcan complicadas a primera vista, poseen una gran comunidad de desarrolladores y de soporte detrás de ellas, lo que asegura que seguirán vigentes por un tiempo razonable.
- Si el problema de la deuda técnica es muy recurrente en las reuniones de equipo, retros, etc... Probablemente es tiempo de tener a un programador dedicado a este tema, o implementar algún tipo de rotación en este rol. Esto es, al largo plazo, una inversión financieramente inteligénte, pero más aún, una señal de respeto y consideración a la salud mental y satisfacción laboral de nuestros colegas.
En fin, este es un listado de acciones de relativamente sencilla implementación, que sin duda colaborarán a crear un ambiente donde el resultado de nuestro trabajo no sea una permanente fuente de frustraciones, sino que, al menos a ratos, nos haga sentir orgullosos.
Top comments (0)