La deuda técnica es un concepto interesante que se ha ido abriendo paso en los titulares de los medios de comunicación en los últimos dos años porque se ha convertido en un problema omnipresente en todo el ecosistema de las aplicaciones. Cada vez más, las organizaciones están discutiendo abiertamente su relación con los problemas, a menudo costosos, que esto crea para su negocio. Esto plantea la pregunta: ¿cuál es el denominador común?
Dependiendo de la empresa, la deuda técnica puede variar en gravedad, desde ser una pequeña mancha en tus gastos de IT y desarrollo de software hasta un «impuesto» agobiante del que aparentemente no puedes escapar. En cualquier caso, es algo que debes intentar minimizar siempre que sea posible. Para ello, es importante entender cómo afecta al negocio, por lo que aquí vamos a explicar qué es la deuda técnica y qué la causa, y luego explicaremos cómo puede afectar a tu capacidad para ofrecer actualizaciones oportunas y necesarias a tu aplicación o producto digital.
¿Qué es la deuda técnica y qué la provoca?
En pocas palabras, la deuda técnica se refiere a los costes adicionales en los que se incurre para refactorizar un producto digital, como una aplicación móvil, debido a las limitaciones impuestas por la aceleración del proceso de desarrollo (en parte o en su totalidad) para cumplir un plazo. En pocas palabras, es el dinero extra que hay que gastar porque algo se ha dejado a medias para ahorrar tiempo.
Por supuesto, hay otras decisiones que también pueden conducir a la deuda técnica. A veces, se elige una tecnología que se considera la «mejor» para su época, pero pierde relevancia con el tiempo o acaba siendo superada por algo nuevo. Un ejemplo de ello es el Windows Communication Framework (WCF), que a mediados de los años ochenta era el principal framework de Microsoft para crear aplicaciones distribuidas. Sin embargo, desde entonces ha sido superado por frameworks más nuevos y sencillos como ASP.NET Web API y muchos otros. A medida que WCF se ha ido desvaneciendo en la memoria, también lo han hecho los conjuntos de habilidades necesarios para modificar y mantener las bases de código construidas sobre ellos.
¿Por qué ocurre esto y por qué es tan común? Consideremos lo siguiente:
Nuestro mundo está construido en torno a la comodidad: prácticamente todas las soluciones que tenemos para cualquier cosa que se nos ocurra suelen facilitar lo que sea. Ya no es necesario cargar un carro y subir a los caballos para ir a casa de la tía Ruth para que te enseñe a preparar su legendario pan desde cero, sino que podéis hornear juntos desde vuestras propias casas a través de FaceTime. Aunque no todas las comodidades modernas eclipsan a sus homólogas de antaño en todos los sentidos, lo cierto es que venden. Y aquí radica un pequeño problema.
Un caballo es una opción infinitamente más eficiente en cuanto a consumo de combustible que un Volkswagen o un BMW, además de tener muchos menos problemas eléctricos, pero si miras a tu alrededor, verás que hay muy pocos caballos en las carreteras. Los líderes emergentes y los ya existentes en un espacio de mercado -como los fabricantes de vehículos alemanes mencionados anteriormente- toman nota y se lanzan de lleno a ofrecer lo que entienden que es valioso a los ojos de su público. Aunque es crucial llegar al mercado rápidamente, como cuando se entrega un MVP, hay una forma correcta de reducir el tiempo y, normalmente, un método aún más atractivo que es todavía más rápido. El problema de elegir esta última opción es que suele preparar el terreno para una experiencia continua y problemática para tus clientes.
La paradoja aquí es que el mercado exige velocidad, lo que hace que los atajos sean atractivos, pero la realidad es que los costes pueden acabar comiéndose el valor que ofrece ser el primero. Dicho esto, a veces asumir una deuda técnica a sabiendas puede compararse con capitalizar ciertas inversiones: a veces, necesitarás pedir un préstamo para salir adelante o simplemente para superar algún obstáculo.
Aunque no se puede ver el futuro para saber con certeza cuándo empezará a decaer la utilidad de una tecnología, se pueden evitar las decisiones que suelen conducir a problemas de deuda técnica. Una de las principales formas en que esto puede afectar a los usuarios es su capacidad para actualizar adecuadamente su aplicación, que discutiremos a continuación.
Cómo la deuda técnica puede afectar a la capacidad de actualizar adecuadamente tu aplicación
Como ya hemos comentado, hay veces en que las empresas experimentan una deuda técnica sin que sea culpa suya. Por ejemplo, a lo largo de los años, muchos lenguajes de programación que en su día fueron las mejores soluciones de su clase (o lo único disponible) se han quedado obsoletos simplemente por una serie de cambios en el hardware y el software que hacen que su propia base sea en su mayor parte ineficaz.
En la actualidad, vemos mucha deuda técnica en forma de mantenimiento de frameworks de aplicaciones híbridas que estaban de moda hace unos años. Con la llegada de verdaderos frameworks multiplataforma como React Native, que no vienen con el mismo bagaje que las aplicaciones híbridas, muchos desarrolladores han abandonado estos frameworks híbridos dejando librerías sin parchear y problemas que han sido introducidos por las nuevas versiones de iOS. Por lo tanto, arreglar y mantener las bases de código construidas en estos frameworks híbridos es cada vez más caro y requiere más tiempo.
Es como cuando la máquina de escribir se popularizó rápidamente porque superaba al bolígrafo en términos de velocidad: la máquina de escribir eléctrica mejoraría el diseño de la original y, si avanzamos hasta hoy, la mayoría de las comunicaciones que enviamos son digitales y nuestras «máquinas de escribir» son sólo piezas de software.
Con el tiempo llegará algo mejor y sustancialmente evolucionado, pero mientras tanto, es importante encontrar soluciones y tomar decisiones centradas en la escalabilidad para las necesidades actuales y el futuro previsible. La idea principal es que tienes que ser capaz de: actualizar tu aplicación en función de las directrices de cada tienda de aplicaciones móviles o correr el riesgo de ser expulsado, corregir errores y hacer mejoras de rendimiento para mantener a los usuarios contentos y añadir nuevas características para aumentar su valor general.
Algunos de los problemas más comunes que pueden conducir a la deuda técnica son los siguientes.
Haz que el %&^# funcione, ¡YA!
A veces, por la razón que sea, un arreglo, una actualización o una nueva función se encuentran con un problema que pone a los equipos en una especie de callejón sin salida. Algunas soluciones, como volver a la «antigua forma» de hacer algo o utilizar un parche difícil de aplicar para sacar algo adelante, acabarán teniendo que ser reformuladas. Además, el software puede actuar, incluso para los desarrolladores, y además, aventurarse en nuevos territorios descubrirá «incógnitas desconocidas» que pueden ralentizar a los equipos y aumentar los costes.
Dejando a un lado los límites de velocidad y las leyes de tráfico, sólo se pueden tomar las curvas a cierta velocidad antes de que el vehículo se deslice hacia el olvido. Claro que llegar al mercado rápidamente es importante, pero hacerlo «bien» suele ser más rentable que «ahora mismo».
Sólo necesitas «algo» en el mercado
Sí, sí lo necesitas. Lo que necesitas es un MVP que haya sido planificado y probado metódicamente, así como una intención subyacente de desarrollarlo de forma iterativa basándose en la retroalimentación y los datos.
Conseguir un MVP ni siquiera significa lanzar un producto muy pulido, ya que la idea es lanzar algo que enganche a tu público objetivo lo suficiente como para que puedas probar el producto en el mundo real y recoger opiniones. Todo debe construirse pensando en el futuro, o bien hay que tener los bolsillos llenos, como Walmart.
La primera aplicación móvil de Walmart era un desastre de aplicación híbrida, que es un estilo de aplicación móvil que no aprobamos. Sin embargo, esta era una práctica común hace una década y les permitió entrar en el mercado en el momento adecuado para seguir intercambiando golpes con otros grandes minoristas en el espacio de las aplicaciones móviles. Pero finalmente, desecharon todo el frontend de la aplicación en favor de React Native.
Obviamente, Walmart tiene bolsillos lo suficientemente profundos como para que esto les funcione. Por diseño, una aplicación híbrida sólo puede ser tan buena, así que eliminaron toda (bueno, la mayoría) la deuda técnica de su aplicación creando un frontend completamente nuevo. La lección aquí es que a veces la única manera de salir de la deuda técnica es básicamente «pagarla por completo».
Las soluciones de bajo código son una receta para el desastre
Hicimos una toma caliente en soluciones de bajo y ningún código el año pasado y el sentimiento sigue siendo el mismo. Aunque estas soluciones no son del todo inútiles -en realidad son ideales para que las personas motivadas construyan sus pruebas de concepto-, carecen intrínsecamente de la personalización en bruto que puede proporcionar la verdadera codificación.
Casi todas las aplicaciones que se basan en este tipo de frameworks suelen encontrarse con un par de problemas. Ciertos sistemas no tienen la flexibilidad necesaria para permitir la edición profunda que es necesaria para la personalización y si funciona bien con el código personalizado, entonces se plantea la cuestión de por qué se está utilizando una solución de este tipo en el primer lugar. Con el tiempo, estos sistemas se llenan de «módulos» de código que hacen mucho más de lo necesario (es decir, son ineficientes desde el punto de vista del código) o hacen demasiado poco. Esto puede conducir a problemas con la aplicación de las actualizaciones necesarias en el futuro, ya sea para una nueva característica o simplemente algunos cambios para aplacar una de las directrices de la tienda de aplicaciones móviles.
No utilizar el desarrollo iterativo
La razón por la que nosotros y otros estudios defendemos el desarrollo iterativo es que se adhiere a casi todas las metodologías ágiles en el sentido de que es flexible. Más concretamente, permite aprender sobre el producto y el público y, a continuación, construir en torno a él mientras se tiene en cuenta la hoja de ruta del producto. Al utilizar una combinación de código personalizado y sólidas API de terceros, podemos crear soluciones a medida con la elasticidad necesaria para crecer con el tiempo.
Desarrollar a gran escala es arriesgado y costoso, especialmente cuando un cambio requiere una revisión masiva. Hacer un poco a la vez ayuda a asegurar que las características funcionan lo suficientemente bien antes de añadir otra capa. Al igual que cuando se construye una casa nueva, es mucho más difícil volver atrás y arreglar un problema de cableado si el proyecto ha pasado a la fase de «lijado de paneles de yeso». Esto también elimina en su mayor parte la posibilidad de cualquier deuda técnica significativa, ya que todo se escala en proporción a los frameworks diseñados para apoyar el producto a largo plazo.
