4 publicaciones etiquetados con "Desarrollo de Software"

Imagina que estás administrando tus finanzas personales. Tienes una tarjeta de crédito, y cada mes miras el porcentaje de tu deuda en relación con tu límite de crédito para saber si estás en una situación saludable o si necesitas tomar medidas. El Índice de Deuda Técnica (TDI, por sus siglas en inglés Technical Debt Index) funciona de manera similar para tu código: te ayuda a entender qué tan "endeudado" está tu proyecto en términos de calidad y mantenibilidad.

¿Qué es exactamente el TDI?​

El TDI es como un termómetro que mide la "fiebre" de tu código. Es un número que va de 0% a 100%, donde un valor más bajo indica un código más saludable. Por ejemplo, si tu proyecto tiene un TDI del 15%, está en buena forma, pero si alcanza el 45%, es momento de preocuparse y tomar acciones.

Esta métrica actúa como un sistema de alerta temprana, permitiéndote identificar cuándo tu base de código comienza a deteriorarse antes de que los problemas se vuelvan críticos. Al igual que un médico monitorea los signos vitales de un paciente, el TDI te ayuda a mantener un ojo constante en la salud de tu proyecto.

Algunos factores que influyen en el TDI incluyen:

• Complejidad ciclomática del código
• Duplicación de código
• Cobertura de pruebas
• Violaciones de estándares de codificación
• Deuda técnica deliberada vs accidental
• Antigüedad del código legacy

Por ejemplo, un proyecto puede tener un TDI bajo del 12% gracias a:

• Revisiones de código regulares
• Refactorización proactiva
• Pruebas automatizadas extensivas
• Documentación actualizada
• Estándares de código consistentes

Mientras que un TDI alto del 60% podría indicar:

• Código duplicado extensivo
• Falta de pruebas unitarias
• Violaciones de principios SOLID
• Dependencias obsoletas
• Documentación desactualizada

El TDI te permite tomar decisiones informadas sobre cuándo y dónde invertir recursos en mejoras técnicas, ayudándote a mantener un equilibrio saludable entre el desarrollo de nuevas características y el mantenimiento del código existente.

Proceso de Estimación de Deuda Técnica en Historias de Usuario​

Para mantener un control efectivo del TDI durante el desarrollo, es importante establecer un proceso claro de estimación. Este proceso se divide en dos pasos principales:

1. Durante la Planificación​

Para cada Historia de Usuario (HU), el equipo necesita realizar dos estimaciones clave:

• Esfuerzo base para desarrollo (EB): El tiempo necesario para implementar la funcionalidad principal
• Esfuerzo para gestión de deuda técnica (EDT): El tiempo adicional requerido para mantener la calidad del código

2. Cálculo del TDI​

Con estas estimaciones, podemos calcular el TDI específico para cada Historia de Usuario:

• Fórmula: TDI_HU = (EDT / (EB + EDT)) × 100

Por ejemplo, si tenemos:

• Esfuerzo base = 8 puntos de historia
• Esfuerzo deuda técnica = 2 puntos de historia
• TDI_HU = (2 / (8 + 2)) × 100 = 20%

Este resultado nos indica que el 20% del esfuerzo total se dedicará a gestionar la deuda técnica.

Rangos aceptados​

Según un estudio realizado por SonarSource en 2023, estos son los rangos generalmente aceptados:

• 0-15%: Excelente salud del código
• 16-30%: Situación manejable
• 31-50%: Requiere atención urgente

• 50%: Situación crítica

🧹 El Caso Netflix​

En 2023, Netflix enfrentó una crisis con un TDI del 40%, lo que afectó severamente sus operaciones. Para solucionarlo, implementaron "Operation Clean Slate", una iniciativa que involucró a 800 ingenieros y estableció días quincenales dedicados a la limpieza de código.

El proyecto se desarrolló en tres fases:

1. Identificación (2 meses): Análisis automatizado que reveló 15,000 problemas técnicos
2. Implementación (3 meses): Priorización y resolución de problemas mediante pair programming
3. Prevención (1 mes): Implementación de gates de calidad y monitoreo continuo

Los resultados después de 6 meses fueron significativos:

• Reducción del TDI del 40% al 15%
• Disminución del 45% en tiempo de resolución de incidentes
• Mejora del 30% en velocidad de desarrollo
• Ahorro proyectado de $50M en dos años

Referencias​

1. SonarSource. (2023). "Managing Technical Debt". SonarSource Documentation.

2. Netflix Technology Blog. (2023). "Fixing Performance Regressions Before they Happen". Netflix TechBlog.

3. Martin, Robert C. (2008). "Clean Code: A Handbook of Agile Software Craftsmanship".

4. IEEE Software. (2023). "Technical Debt: From Metaphor to Theory and Practice". IEEE Software Journal, 40(2), 8-17.

¿Alguna vez has mirado tu código y pensado que, aunque funcional, podría parecer más profesional? Lo que diferencia a un desarrollador senior no es solo la lógica, sino también la claridad y la estructura en cada línea.

Escribe código legible para humanos, no sólo para máquinas.

¿Sabías que los desarrolladores pasan alrededor del 50% de su tiempo leyendo código escrito por otros? La legibilidad ya no es opcional, es una necesidad. La claridad del código es una de las claves para reducir la deuda técnica, ya que muchas veces es algo que dejamos pasar con el tiempo. Es importante tener en cuenta una serie de parámetros para que nuestro código se vea más profesional.

Evita las iteraciones anidadas

Como líder técnico, algo que veo con frecuencia es el uso de iteraciones anidadas, las cuales hacen muy tediosa la lectura del código. Aunque esto puede deberse a una estructura de datos mal planteada, muchas veces es más sencillo disminuir la complejidad del algoritmo desde cómo procesamos la información.

Aquí dejo un ejemplo que nos ayuda a entender esto:

 const data = [ 
        { category: 'A', values: [1, 2, 3] }, 
        { category: 'B', values: [4, 5] }, 
      ]; 
      
      data.forEach(item => {
        item.values.forEach(value => {
          console.log(`${item.category}: ${value}`);
        });
      });

A continuación, un ejemplo de cómo manejarlo correctamente:

const data = [ 
  { category: 'A', values: [1, 2, 3] }, 
  { category: 'B', values: [4, 5] }, 
];

function logValues(category, values) {
  values.forEach(value => {
    console.log(`${category}: ${value}`);
  });
}

data.forEach(item => logValues(item.category, item.values)); 

Válida siempre tus arreglos antes de operar con ellos

Otra práctica que veo comúnmente es el uso de métodos propios de los arreglos sin validar previamente que la variable sea efectivamente un arreglo. En JavaScript, los datos no son tipados, lo que permite que su tipo cambie, o que variables solo estén inicializadas sin tener un valor asignado.

Aquí dejo un ejemplo que nos ayuda a entender esto:

const items = undefined;
const filteredItems = items.filter(item => item > 2);

Y a continuación, un ejemplo del manejo correcto:

const items = undefined;

if (Array.isArray(items)) {
  const filteredItems = items.filter(item => item > 2);
}

Evita las funciones ternarias anidadas

Un tema que para mí también es de gran importancia es el uso de funciones ternarias anidadas. Aunque las funciones ternarias son útiles para escribir código más limpio, pueden convertirse en un dolor de cabeza cuando se anidan.

Aquí un ejemplo que nos ayuda a entender esto:

const getStatus = (status) => {
  return status === 'success' ? 'Operación exitosa' :
         status === 'error' ? 'Hubo un error' :
         status === 'loading' ? 'Cargando...' :
         'Estado desconocido';
};

Y este es un ejemplo de cómo manejarlo correctamente:

const getStatus = (status) => {
const getStatus = (status) => {
  const statusMessages = {
    success: 'Operación exitosa',
    error: 'Hubo un error',
    loading: 'Cargando...',
  };

  return statusMessages?.[status] || 'Estado desconocido';
};

No permitas que la deuda técnica se acumule

Podría enumerar muchos otros problemas que surgen, en su mayoría, por el afán y que permiten que la deuda técnica se acumule. Mi invitación a los equipos de desarrollo es a que presten atención a este tipo de prácticas y no dejen pasar por alto este tipo de código. Esto habla mucho de la calidad del trabajo que realizan y, aunque pueda parecer algo básico, démosle la importancia que merece.

El Impacto Real en los Proyectos​

Traigamos a la realidad el tema de la deuda técnica, que muchas veces parece un fantasma en el camino de las empresas. Para entenderlo mejor, hagamos un ejercicio mental: imaginemos que estamos en medio de un parque industrial donde los cables eléctricos no están bien señalizados, y el orden de estos elementos básicos es inadecuado para el contexto. Estos errores en la infraestructura pueden causar accidentes o retrasos en el mantenimiento y la elaboración de funcionalidades.

De la misma manera, la deuda técnica impacta el desarrollo: como cables tirados sin señalización, que cualquiera podría pisar. Un cable o código mal gestionado, o sin documentar, puede generar problemas que dificulten la integración de nuevas funcionalidades y aumenten los tiempos de entrega.

El Peligro de Ignorar la Base: ¿Estás Preparado para Escalar?​

Pasar por alto la necesidad y prioridad de los diferentes elementos es, muchas veces, lo que nos lleva a cuestionarnos si lo que estamos experimentando es realmente tangible. En numerosas ocasiones, la entrega de funcionalidades en una etapa temprana puede dar la impresión de que estamos superando las expectativas en el desarrollo del producto. Sin embargo, no siempre somos conscientes del costo oculto de cada una de estas funcionalidades.

"La única manera de ir rápido es yendo bien." — Kent Beck, Extreme Programming Explained

Si priorizamos funcionalidades que se escriben sobre módulos que no tienen un funcionamiento del todo acertado, ¿cómo esperamos que se comporten estas funcionalidades? Si visualmente agregamos características sobre algo que no se ve bien, ¿cómo esperamos que se vea esta nueva funcionalidad que estamos agregando? Aquí surge una cuestión importante: ¿cómo debemos priorizar las nuevas tareas para que todo vaya sobre ruedas?

El Costo del Crecimiento Desordenado​

Si no se examinan con detalle, de la mano de un experto, estas funcionalidades podrían "esconder bajo la alfombra" problemas que, a medida que nuestro producto crezca, nos harán cuestionar si realmente es funcional. El crecimiento de un producto puede verse afectado no sólo en términos de tiempos de desarrollo, sino también por el aumento de fallos y errores en las diferentes etapas, lo que genera graves retrasos.

Sumemos a esto el constante cambio que los productos de hoy en día demandan. Los usuarios están acostumbrados a la novedad constante; los productos no pueden detenerse, y hacerlo podría tener costos altísimos, no sólo en términos de reputación, sino también en retrasos. Mientras la tecnología avanza a un ritmo acelerado, si el crecimiento del producto no lo hace, quedará rezagado en la obsolescencia.

Llamado a la Acción​

A los lectores de estas entradas, los invito a que aceleremos los productos desde la priorización, saldemos la deuda técnica y avancemos para que las ideas se conviertan en realidades.

"El código desordenado es un lastre que ralentiza el desarrollo futuro y dificulta la incorporación de nuevas funcionalidades." — Robert C. Martin, Clean Code

La Deuda Técnica: El Enemigo Silencioso​

Imaginemos trabajar en un sistema donde cada cambio o mejora puede generar una cascada de fallos y errores significativos, impidiendo que continuemos con el desarrollo normal del proyecto. Esto es lo que ocurre cuando no prestamos la atención necesaria a la deuda técnica, la cual genera un costo que "cobra su cheque" cuando intentamos implementar nuevas funcionalidades.

El Desafío del Código Legacy​

Ejemplos de esto abundan en el mundo de la tecnología. Podemos hablar del código legacy: quienes tenemos experiencia en este campo hemos desarrollado una habilidad que, en un mundo ideal, no deberíamos necesitar, y es la capacidad de interpretar funcionalidades tipo spaghetti, donde las mismas están entreveradas y son difíciles de seguir. Tras horas de interpretación, apenas logramos unos minutos de ejecución efectiva.

Mantenimiento y Actualización​

En este punto, es importante mencionar no solo el mantenimiento, sino también la actualización de la infraestructura. Desde el liderazgo técnico de una empresa, no solo se debe buscar generar valor a través del producto, sino también estar al día con las actualizaciones tecnológicas. Aunque el ritmo de una empresa puede empujarnos a mantener la estabilidad en los stacks y tecnologías actuales, no debemos olvidar que estamos en un mundo tecnológico en constante actualización. Ignorar estas novedades podría llevarnos a quedar rezagados frente a la competencia.

Conclusiones y Recomendaciones​

La deuda técnica nos permite avanzar rápidamente, como una deuda crediticia, pero es esencial tomar pausas para solventar estos vacíos antes de que se acumulen. Aunque lo ideal sería no tener ninguna deuda técnica, quienes trabajamos en esta industria sabemos que es un tema complejo que no podemos ignorar.

Preguntas para Reflexionar​

• ¿Es el gap de cada funcionalidad el necesario para evitar generar deuda técnica?
• ¿El equipo se toma el tiempo necesario para evaluar si existe deuda técnica?
• Si ya tienes deuda técnica, ¿está el producto pasando por la pausa necesaria para poder limpiarla?

La invitación es a dejar de tratar este tema como un fantasma: ¡es una realidad! Y los principales afectados no son los desarrolladores, sino el producto.

"Ignorar la deuda técnica es posponer lo inevitable: en algún momento tendrás que pagar el precio de un código mal diseñado." — James Shore, The Art of Agile Development

🙏 Agradecimiento​

Antes de iniciar con esta entrada, quiero dar un agradecimiento a este gran camino que ha significado convertirme en un TL, un puesto soñado por muchos y que otras personas detestan. Es un rol complejo desde su base técnica y que tiene un importante componente humano de cercanía, difícil de ejecutar pero extremadamente gratificante. Gracias a la vida por ponerme en este hermoso camino, desde el cual puedo ayudar y construir en la profesión que amo.

📝 Introducción​

Hoy me di este momento para escribir una entrada de blog. No quiero que se confunda esta entrada, pensando que basta con el aspecto humano para ser un líder técnico. Hay que tener unas bases muy sólidas en el aspecto técnico para liderar un equipo, dado que para ser un líder no basta con tener el cargo; se debe ganar el respeto del equipo. Como todos los líderes sabemos, el respeto de un equipo técnico se gana demostrando que se tiene la habilidad de diseñar e implementar soluciones complejas, y de destrabar desde lo técnico cualquier requerimiento, por muy complejo que sea.

Sin embargo, siento que el camino de un TL no es para nada lineal y está lleno de momentos. Esta reflexión no debería ser tomada como la generalidad del liderazgo; es una visión planteada desde mi experiencia personal, seguramente sujeta a mucha reflexión. Liderar un equipo es un viaje diario lleno de complejidades, y para el que siento que no todos estamos preparados.

💪 Retos diarios de un TL​

Lo increíble de ser TL es que cada día encuentras una nueva pregunta y un reto diferente en muchos ámbitos, tanto técnicos como personales. Sin embargo, los más complejos son los inherentes al liderazgo de un equipo humano, como muestra:

¿Cómo llevar tranquilidad a un equipo que siente que no es suficiente? ¿Cómo liderar desarrolladores que tienen un talento innato que muchas veces percibes como un potencial gigante para llevarlos a su cumbre? ¿Cómo aumentas el rendimiento del equipo sin sacrificar la estabilidad del mismo?

Estos retos y preguntas son un ejemplo de lo que conlleva el diario vivir de mi trayectoria como líder.

🤔 No hay respuestas​

No hay respuesta para estas preguntas. No hay un solo camino para ejercer el liderazgo, no es tan simple como eso; ojalá lo fuera. En lo que más he encontrado respuestas es, definitivamente, en el ámbito humano. Tengo la certeza, y en mi trayectoria como líder he comprobado, que las personas, sobre todo aquellas con gran potencial, no se bloquean por el ámbito técnico; se bloquean como respuesta a factores de su vida, a sentirse inconformes con el trabajo que hacen, a no estar cumpliendo sus sueños, a sentirse estancados. Definitivamente, el factor técnico, aunque importante, puede entrar en segundo plano.

Como desarrollador, siento que tengo la habilidad técnica para solventar los problemas que se presenten. Sin embargo, como líder, siento que la tarea más compleja es llegar a la parte humana de los equipos para poder transformarlos desde el fondo.

Desde mi experiencia, hablar con el equipo un momento sobre cómo estuvo su día, cómo van las cosas con la familia, cómo está todo en su vida, cómo se siente con el trabajo que está haciendo, cómo se siente desenvolviéndose en el proyecto, hace que el aspecto técnico empiece a fluir de una manera increíble. Sin embargo, esto no es una fórmula mágica.

🌟 El liderazgo no tiene fórmulas mágicas​

Estoy seguro de que el liderazgo no tiene una fórmula mágica, ni tiene estándares en su forma. Es una tarea, no solo del líder, sino de todos los miembros del equipo. Sin embargo, mantener esa cohesión en un equipo es una gran responsabilidad que debe asumir un líder en su labor. Desde mi posición como líder, los invito a que construyan sus equipos desde lo humano.

Les deseo que, si son líderes, los retos y preguntas que trae este viaje diario sean resueltos día con día y paso a paso.

💡 Nota: Las reflexiones compartidas en este artículo están basadas en experiencias personales y pueden variar según el contexto y equipo específico.