Sí, por más extraño que parezca, además de ser un juego muy entretenido y adictivo desde hace años, tetris también es una excelente analogía para entender qué es y qué implica la deuda técnica en nuestras compañías. Aunque no seamos tan conscientes de ello, la deuda técnica es algo con lo que lidiamos prácticamente todos los días y estamos bastante familiarizados como profesionales dentro del ramo de los Sistemas IBM i – AS/400, y en este artículo entenderemos por qué.
Como desarrolladores de software, estamos en constante comunicación con las diferentes áreas estratégicas de negocio para poder realizar programas adecuados a sus necesidades. Necesitamos crear y modificar código continuamente para ajustarnos a las exigentes demandas del mercado y la operación que evoluciona conforme la empresa crece; constantemente entregamos y desplegamos nuevos programas o funciones añadidas a los programas para cumplir los requerimientos del negocio.
Digamos que cada programa o función se puede visualizar como una línea horizontal de tetris, entre más complejo el programa, más líneas ocuparía en el juego. Cuando el negocio comienza y se empieza a crear todo desde cero, es como los primeros niveles ya que son los menos complejos en los que todo avanza sin contratiempos, vamos construyendo líneas perfectas y sin huecos.
Conforme va avanzando el juego, la velocidad con la que caen las piezas comienza a aumentar, nos da menos tiempo para pensar en dónde vamos a acomodarlas, por lo que comenzamos a generar brechas en el juego que a su vez nos limitan más el espacio para maniobrar y no hay forma de frenar el flujo de piezas; como la operación del negocio, tiene que seguir y uno se tiene que acomodar como pueda.
Esto se puede interpretar, por ejemplo, cuando las necesidades del negocio exigen nuevas funciones que por la falta de tiempo y recursos se recurre a realizar harcodeo, hacks o atajos que logran la función que se busca pero no de forma escalable, de tal manera que tarde o temprano tendremos que regresar a modificar esa función ya que no es sostenible mantenerla así. O cuando se crean programas “nuevos” con la lógica de los programas viejos pero combinada con una nueva lógica que logra cumplir con alguna necesidad específica de negocio y que termina siendo un programa el cual nadie entiende bien cómo está construido.
Escenarios como estos crean deuda técnica, esas brechas que quedan enterradas en algún lugar del juego y que nos provocan dificultades para operar dejando de ser competitivos o, en el peor de los casos, perder el juego. Se le denomina como “deuda” porque tarde o temprano tendremos que pagarla, ya sea con esfuerzos para modificar el código o con pérdidas financieras del negocio; y entre más tiempo nos tardemos en pagarla, más altos serán los intereses.
La deuda técnica siempre existe, es prácticamente imposible desarrollar tecnología tan perfecta y, como en el tetris, es posible mantener un buen juego con algunas brechas. Sin embargo, cuando las brechas son demasiadas, se vuelve insostenible seguir avanzando por lo que debemos buscar un balance.
Similitudes entre el tetris y las compañías:
Ahora que ya tenemos claro qué es la deuda técnica y por qué ocurre, dimensionemos toda la analogía a las empresas que cuentan con Sistema IBM i – AS/400. En su mayoría son grandes compañías con más de 30 años de trayectoria con programas y desarrollos complejos que no pueden frenar su operación porque representaría una pérdida importante de dinero.
Aunado a que existen ya bastantes líneas en el juego por el tiempo que ha pasado, la rotación de los programadores y la falta de documentación ha creado un escenario en donde las empresas saben que tienen esas brechas en su tecnología, pero no saben en dónde ni cómo cerrarlas. Hoy en día se cuentan con muchas buenas prácticas para tener control y generar código limpio. Sin embargo, antes casi no se utilizaban (por desconocimiento) buenas prácticas para generar código limpio y es lo que hoy en día nos está cobrando factura.
Desafortunadamente no es un problema que se pueda solucionar fácilmente contratando más programadores o cambiando el equipo de desarrollo por otro con mayor experiencia. Esto porque la solución se encuentra en el conocimiento y exploración de las brechas existentes, es necesario hacer una auditoria minuciosa al código para generar una base de conocimiento y que se puedan crear proyectos con objetivos y alcances claros.
Para el caso puntual de IBM i – AS/400, existen soluciones como Arcad Software, que además de ser una herramienta muy robusta para modernizar el Sistema en general, una de sus funciones principales es realizar auditorías de código legacy para poder tener claro el punto de partida y tener un reporte automático con información clave de la situación actual.
Disminuir al máximo la deuda técnica también ayudará a cambiar el enfoque del área de tecnología, ya que en ocasiones las diferentes unidades de negocios visualizan a los equipos de IT como personal de soporte (un mal necesario) en vez de vernos como un área estratégica capaz de potencializar cualquier sección de la compañía.
