¿Te acuerdas de cuando querías que tu código fuera una obra de arte?
Yo sí. Me acuerdo perfectamente de mis primeros años como desarrollador. Me pasaba las noches leyendo sobre Clean Architecture, patrones de diseño complicadísimos y cómo aplicar SOLID hasta en el más mínimo componente de React. En mi cabeza, si el código no era académicamente perfecto, sentía que estaba fallando como profesional. Me obsesionaba con esa abstracción elegante que, según yo, permitiría que el software escalara hasta el infinito sin fricción. Pero la realidad, esa que no viene en los libros de arquitectura, terminó dándome una bofetada de realidad bastante necesaria.
Mi experiencia con la sobreingeniería
Hace unos años, estuve trabajando en una startup que necesitaba sacar un MVP (Producto Mínimo Viable) en tiempo récord. ¿Qué hizo el Roberto de aquel entonces? En lugar de centrarse en lo que el usuario necesitaba ver en pantalla, me encerré tres semanas a diseñar un sistema de gestión de estado ultra genérico y una capa de servicios que parecía sacada de la NASA. Estaba orgulloso. El código era precioso, las interfaces eran impecables y todo estaba desacoplado hasta el extremo.
¿El resultado? Llegamos tarde. Cuando por fin presentamos la funcionalidad, el mercado había cambiado, el feedback de los usuarios fue totalmente distinto a lo esperado y tuvimos que borrar el 80% de ese código perfecto que tanto me había costado escribir. Ahí fue cuando me dolió. Me di cuenta de que había gastado tiempo y dinero de la empresa en resolver problemas técnicos que ni siquiera existían, mientras descuidaba el problema real que el negocio intentaba solucionar. Fue un punto de inflexión brutal en mi carrera.
¿Por qué ahora me importa más el negocio?
A ver, no me malinterpretes. No estoy diciendo que ahora escriba código espagueti o que me dé igual la calidad. Lo que pasa es que he cambiado mi definición de calidad. Antes, calidad era cumplir con todos los patrones del libro de Uncle Bob. Hoy, calidad es entregar una solución robusta que ayude al usuario hoy, no dentro de seis meses. El código es un medio para un fin, no el fin en sí mismo.
He aprendido que el código tiene un coste de mantenimiento. Cada línea que escribimos es una responsabilidad más. Si creo una abstracción compleja para algo que quizás nunca cambie, estoy añadiendo una carga cognitiva innecesaria a mis compañeros (y a mi yo del futuro). El negocio necesita agilidad. Necesita probar hipótesis rápido. Si mi arquitectura es tan rígida o tan compleja que tardamos semanas en cambiar un botón de sitio, entonces mi arquitectura es mala, por muy clean que parezca en el diagrama.
Lo que he aprendido en el camino
Ahora aplico una regla mental muy sencilla: YAGNI (You Ain't Gonna Need It). Si no tengo una razón de peso hoy para abstraer algo, no lo hago. Prefiero repetir código tres veces antes de crear una abstracción prematura que nos encasille. He aprendido a amar la simplicidad, incluso si eso significa que el código no parezca tan inteligente a primera vista.
Otra lección importante ha sido entender la deuda técnica como una herramienta financiera. A veces, tiene sentido tomar un préstamo de deuda técnica para llegar a una feria tecnológica o para cerrar una ronda de inversión. Lo importante no es no tener deuda, sino saber que la tienes y tener un plan para pagarla cuando el negocio esté validado. No es pereza, es estrategia.
A menudo me encuentro en discusiones técnicas donde alguien propone una solución increíblemente compleja para un caso de borde que ocurre el 0.1% de las veces. Mi respuesta suele ser: ¿Cómo afecta esto al valor que entregamos al cliente? Si la respuesta es poco o nada, prefiero la solución sencilla aunque no sea la más elegante desde el punto de vista de la ingeniería pura.
Reflexiones finales
Si eres como yo y te encanta la técnica, es fácil caer en la trampa de construir catedrales cuando el cliente solo necesita un refugio para la lluvia. Mi consejo, después de muchos errores, es que hables más con la gente de producto, que entiendas por qué el usuario usa tu herramienta y qué es lo que realmente les duele. Al final del día, a nadie le importa si usas Hexagonal Architecture o si tu folder structure es perfecta si la aplicación no funciona o no aporta valor. El mejor código es el que ayuda a que el negocio prospere, el que se puede cambiar con facilidad y, sobre todo, el que llega a producción a tiempo.