Cuidado: la reconstrucción no es la única solución para superar la deuda tecnológica Cinco tácticas que lo guiarán para reconocer signos de deuda tecnológica y los riesgos involucrados mientras lo convierten en un tomador de decisiones maduro.

¿Qué haces como líder técnico si no estuviste allí desde el principio? ¿O si no fueras tú quien escribió la primera línea de código? ¿Cómo se toman decisiones tecnológicas futuras sin conocer el pasado? No permita que la presión o la falta de paciencia lo lleven a elegir ciegamente la ruta de reconstrucción. Hay esperanza.

Este artículo lo guiará para reconocer los signos de la deuda tecnológica, los riesgos involucrados y lo ayudará a considerar cinco tácticas para aumentar su Cociente de calidad tecnológica (TQQ) general y convertirlo en un tomador de decisiones maduro.

La tecnología de hoy es la deuda de mañana. Así es como el software vive su vida. Sin embargo, la calidad del código comprometida puede hacer que el desarrollo del producto se detenga por completo, que el equipo de ingeniería se arrodille y cause el tipo de frustración creciente que conduce al desgaste del talento.

Tenemos demasiada deuda tecnológica. "Reconstruyamos todo el sistema y hagámoslo bien esta vez" parece una respuesta apropiada cuando estás en medio de todo. Una elección de reconstrucción impulsada por las emociones podría convertirse en una trampa si no está preparado.

El popular libro de Martin Fowler Refactoring: Improving the Design of Existing Code y los blogs de Justin Fuller , Joel Spolsky y David Boyne han expresado pensamientos similares.

Relacionado: No existe tal cosa como una aplicación libre de errores

Señales de que tienes deuda tecnológica

• Su equipo actual no escribió el código antiguo ni lo entiende.

  • Precio que paga: la falta de familiaridad con el dominio del problema puede resultar en problemas de escalado y depuración.

• El ritmo de cambio se ve afectado negativamente y cada lanzamiento rompe más cosas de las que arregla.

  • Precio que paga: costo de no poder expandir la arquitectura a escala

• Los desarrolladores no quieren trabajar en tu stack tecnológico y no puedes encontrar talento con las habilidades requeridas.

  • Precio que paga : los profesionales de la tecnología quieren mejorar sus habilidades con tecnología de punta. Encontrar a alguien para mantener los sistemas antiguos es más difícil y costoso.

• Confía en la personalización y administración manual.

  • Precio que paga: las soluciones manuales nunca pueden escalar a la velocidad de la tecnología.

• De manera predeterminada, toma decisiones como despeje, no ser arreglado o el próximo lanzamiento de manera consistente. Son fáciles de seleccionar desde un menú desplegable de su software de seguimiento de tareas. Pero pueden tener un impacto duradero en la psique o en la cultura de su organización.

  • Precio que paga: Oportunidad perdida debido a ciclos de desarrollo prolongados más lentos.

• Te rompes, tu propia falacia: cuando notas que los miembros del equipo tienen miedo de tocar piezas de código. Ya sea porque temen romper la funcionalidad existente o poseer la mantenibilidad futura. Si es así, es hora de intervenir y limpiar.

  • Precio que paga: falta de seguridad emocional, seguridad, propiedad y cultura de responsabilidad.

Estos son algunos ejemplos de deuda tecnológica con la que mis equipos han lidiado en el pasado:

• Frontend y backend estrechamente acoplados

• Migración a tecnología frontend de última generación: ES5 a Next.js

• Sin canalización de CI/CD

• Falta de observabilidad a nivel de aplicación y sistema

• Indexador por lotes fuera de línea basado en Lucene VS Motor de búsqueda en tiempo casi real usando Solr

• No se puede seguir claramente el ciclo de vida completo de una solicitud

• Un modelo de datos sobreajustado para soportar múltiples casos de uso. (El caso de uso más común es combinar los modelos de notificación, bandeja de entrada y mensajería como uno solo).

• Más de una solución tecnológica para hacer casi lo mismo

• Productividad y satisfacción de los desarrolladores

Ningún líder de ingeniería quiere transmitir mensajes a sus ejecutivos y miembros de la junta de que no habrá desarrollo de nuevas características. Sin embargo, Apple en 2018 se vio obligada a hacer precisamente eso. Apple, en su Conferencia Mundial de Desarrolladores de 2018 , anunció que iba a reducir el número de funciones en los próximos lanzamientos de iOS para concentrarse en la calidad, la seguridad y el rendimiento. Esto sugiere que están sacrificando nuevas funciones por lo que debería haber estado allí en primer lugar.

Evitar pagar su deuda tecnológica es malo, y apresurarse a reconstruir desde cero es aún peor. La realidad es que se ha utilizado, probado y corregido el código antiguo. Cuando desechas el código y comienzas desde cero, estás desechando todo ese conocimiento. Todas esas correcciones de errores recopiladas. Años de duro trabajo.

Aquí hay cinco consideraciones tácticas:

1. Desarrolla una buena estrategia de transformación digital

Difícilmente se encontrará en un estado en el que pueda desechar toda la implementación de su producto. En la mayoría de los casos, se enfrentará a decisiones sobre cómo aumentar las competencias creadas en el pasado con nuevas capacidades que ofrecen una ventaja competitiva en la economía digital.

Haz tu trabajo preliminar como un arqueólogo. Haz una lista de lo que es intencional versus accidental. Qué se puede reemplazar y con qué se debe trabajar. Una buena estrategia digital debería permitir ambos. David Boyne sugiere usar Event Storming. Todavía no lo he usado, pero David dice que es una buena manera de lograr que un equipo comience a documentar y comprender el dominio en el que están operando.

2. Riesgo de retención de clientes

¿Sus clientes se adaptarán a su nuevo sistema? ¿Los estás ralentizando? A los clientes no les importa si las cosas están escritas en PhP, angular o React, les importa si la aplicación les ayuda a hacer su trabajo.

• Poco después de su salida a bolsa en 2011, La infraestructura de LinkedIn casi colapsa. LinkedIn inició Project Inversion para abordar su tecnología de una década que necesitaba una revisión importante. El renacimiento de la tecnología de LinkedIn ha tenido algunos costos, incluidos cambios constantes que han molestado a algunos usuarios.

3. Divídalo

Comience poco a poco, mantenga la paridad con la funcionalidad anterior. Cree un sistema que le permita desactivar los cambios nuevos y volver a los anteriores si descubre un comportamiento inesperado.

Las actualizaciones incrementales ofrecen una buena estrategia para evitar tiempos de inactividad importantes . Soy un gran defensor de Kaizen, un concepto japonés. Significa mejora continua y sigue siendo clave para la fortaleza de Japón en el mantenimiento de una alta calidad del producto.

4. ¿Cuándo podría considerar la ruta de reconstrucción?

• Cuando no tienes el mismo equipo de programación que trabajó en la versión 1, o en realidad no tienes más experiencia. Para desarrollar experiencia funcional en el dominio con su nuevo equipo, una reconstrucción simultánea actúa como un campo de entrenamiento.

• Fomente el aprendizaje en un entorno pequeño, pero controlado, rompiendo cosas y construyéndolas de nuevo. Qué tan pequeño rompa las cosas es algo que podrá decidir en función de su experiencia para manejar los riesgos.

• Cuando se trata de cambios arquitectónicos centrales.

• Bajos costos de alojamiento: debido a la innovación en la computación en la nube, mantener dos sistemas simultáneamente es más rentable que nunca con la bifurcación del tráfico para las pruebas Beta.

  • Instagram experimentó esto desde el principio cuando lanzó originalmente su aplicación para iPhone, ejecutando sus operaciones desde un único servidor en Los Ángeles. Después de que una avalancha de tráfico casi colapsara el servidor, Instagram cambió (¡en tres días!) a una base de datos alojada en EC2, agregando los recursos adicionales para mantenerlos en movimiento. El cofundador Mike Krieger comparó la transferencia con una cirugía a corazón abierto. Prometió que en el futuro abordarían de manera preventiva la deuda técnica antes de que conduzca a una catástrofe.

Por último, pero no menos importante, no se olvide del aspecto más importante de todo. La mentalidad y el tejido cultural.

5. ¿Qué hay para mí?

Como líder, puede ganar mucho si trata la limpieza de la deuda tecnológica como una responsabilidad estratégica de alto nivel de la organización. Adjunte incentivos especiales para que su equipo quiera hacer el trabajo. Si crea una cultura en la que se financian, reconocen y premian características llamativas en lugar de reparar los sistemas existentes, ¿por qué alguien querría asumir ese trabajo por usted?

La gente teme volver a trabajar, los equipos quieren codificar una vez y olvidarse de eso. Esta tendencia no es buena porque como resultado se tiende a evitar mantener el código. Redefina el desarrollo como un proceso repetible de volver a las funciones en cada iteración y mejorar o abordar los cambios. No dejes tus características atrás. No se pueden codificar y olvidar. Cambia la mentalidad de tu equipo hacia el desarrollo continuo.

Relacionado: Cómo la IA transformará el desarrollo de software

Conclusión

No hay una bala de plata para resolver la deuda tecnológica. No es una tarea que se hace una vez. Requiere un compromiso continuo, la aceptación del liderazgo y ser parte de los hábitos de higiene técnica diaria. No se arriesgue a la bancarrota tecnológica: pague su deuda tecnológica dirigiendo los resultados hacia ganancias significativas de rendimiento, estabilidad, seguridad y mantenibilidad.

Relacionado : ¿Por qué las grandes empresas como Google todavía tienen errores en sus...