Menos dependencias, sistemas más sólidos

Existe una seducción en el desarrollo de software moderno. Para cada problema, hay un paquete. Para cada fricción, un plugin. Nos tienta la promesa de velocidad inmediata: “Instala esto y el problema está resuelto”.

A corto plazo, la promesa se cumple. La funcionalidad se entrega. El ticket pasa a “Hecho” y nos sentimos productivos.

Pero el software no es un artefacto estático; es un sistema vivo. Cuando evaluamos el coste de una funcionalidad, a menudo solo calculamos el tiempo de desarrollo. Omitimos el coste mucho mayor: el tiempo para mantenerlo funcionando. El mantenimiento de software no consiste en arreglar errores de tu propia lógica, sino en gestionar la fricción de tus dependencias.

Cuanto más código externo importas, menos dueño eres de tu sistema.

La dependencia es deuda

Cada dependencia —ya sea una pequeña utilidad, un framework de UI o un servicio de terceros— es un contrato. Intercambias control por comodidad. Aceptas un alquiler de mantenimiento permanente a cambio de un impulso de velocidad temporal.

Considera el ciclo de vida de una dependencia significativa.

• Día 1: Resuelve el problema perfectamente. El equipo está feliz.
• Año 1: La librería lanza un cambio incompatible (v2.0). Debes pausar el trabajo nuevo para refactorizar tu código, o elegir quedarte en una versión sin soporte.
• Año 3: El mantenedor pierde interés o la comunidad se mueve a una herramienta “más nueva y mejor”. Los problemas se acumulan. Aparecen vulnerabilidades de seguridad. Ahora eres dueño de este código, lo entiendas o no.
• Año 5: La librería entra en conflicto con otro sistema central que necesitas actualizar. Estás atascado. El “tiempo ahorrado” hace cinco años se ha pagado con creces e intereses.

Este es el coste operativo oculto de la complejidad. Un sistema ágil con código base propio y fundamental puede tardar un 20% más en construirse inicialmente. Pero un sistema pesado construido sobre una torre de abstracciones requerirá un 200% más de esfuerzo para mantenerse vivo durante una década.

A menudo asumimos que las librerías “estándar” son más seguras que el código propio. Pero a largo plazo, el único código en el que realmente puedes confiar es el que puedes leer, depurar y arreglar tú mismo.

La ilusión de la modularidad

Nos decimos a nosotros mismos que las librerías hacen nuestro código más modular. En la práctica, a menudo introducen “código de integración”: la lógica desordenada y frágil necesaria para hacer que dos sistemas obstinados hablen entre sí.

Cuando dependes fuertemente de dependencias, tu equipo deja de resolver un problema de negocio y empieza a resolver un “problema de integración”. Pasan sus días luchando contra archivos de configuración, incompatibilidades de versiones y errores oscuros enterrados en una carpeta node_modules.

Además, las dependencias aumentan la carga cognitiva para cada nuevo ingeniero. En lugar de aprender el lenguaje y tu dominio, deben aprender el lenguaje, tu dominio y las idiosincrasias de la API de una docena de herramientas de terceros.

Principios para un sistema más fuerte

Esto no es un argumento a favor de reinventar la rueda. No deberíamos escribir nuestra propia criptografía, bases de datos o protocolos de red de bajo nivel. Sin embargo, la postura por defecto de ingeniería debería ser el escepticismo, no la adopción.

Aquí hay algunos principios para guiar esa decisión:

1. Prefiere la plataforma sobre las librerías

Los navegadores y los sistemas operativos son poderosos. CSS, JavaScript y las utilidades estándar de Linux han evolucionado eficazmente. Antes de recurrir a una librería para manejar fechas, animaciones, formularios, etc., pregúntate: “¿Puede el navegador hacer esto nativamente?”

A menudo, la API estándar es más estable, más eficiente y tiene garantía de existir en diez años. La librería no. La plataforma es la dependencia definitiva; apóyate en ella.

2. Sé dueño del camino crítico

Si una pieza de lógica es central para tu valor único, probablemente deberías escribirla tú mismo. Externalizar tu dominio principal a una librería genérica significa que estás limitado por las decisiones de diseño de otra persona. Cuando tus necesidades divergen de las suyas, te encuentras con un muro.

Si tu producto es un panel de control, no delegues la lógica de gráficos a una abstracción de alto nivel que oculta el bucle de renderizado. Sé dueño de lo que te hace valioso.

3. Evalúa la estrategia de salida

Antes de ejecutar npm install o pip install, pregunta: “Si tuviera que eliminar esto en dos años, ¿cuánto tiempo tomaría?”

Si una dependencia crea una telaraña generalizada a través de tu base de código, es un matrimonio de alto riesgo. Si se asienta limpiamente detrás de una interfaz que controlas, es una herramienta manejable. Aísla tus dependencias para que puedas reemplazarlas sin reescribir tu aplicación.

4. Lo aburrido es resiliente

Las nuevas herramientas florecen y se marchitan. El “stack moderno” de 2020 ya parece anticuado hoy. SQL, HTML y HTTP son aburridos. También son atemporales.

Construir sobre tecnología aburrida es la mejor manera de asegurar que tu sistema sobreviva al ciclo de hype. “Aburrido” significa que existe documentación. “Aburrido” significa estabilidad. “Aburrido” significa que duermes por la noche.

El juego a largo plazo

Necesitamos cambiar nuestro pensamiento de “¿qué tan rápido podemos construir esto?” a “¿cuánto tiempo podemos mantener esto?”

La complejidad es el asesino silencioso de los proyectos digitales. Se cuela, un paquete a la vez, hasta que el sistema se vuelve demasiado caro de cambiar y demasiado frágil de tocar. Los sistemas más fuertes son a menudo los que tienen menos partes móviles. Son más fáciles de asegurar, más fáciles de optimizar y más fáciles de traspasar a la siguiente generación de ingenieros.

Cada vez que añadimos una dependencia, estamos invitando a un extraño a nuestra casa. Implica confianza. Implica una relación a largo plazo. Deberíamos ser mucho más precavidos para firmar esos contratos.

En un mundo obsesionado con nuevas herramientas, la decisión de ingeniería más avanzada es a menudo la elección de usar menos de ellas.