A menudo los proyectos no se dañan por falta de técnica, se dañan por exceso de la misma.
Intentar resolver demasiado pronto la escalabilidad, la flexibilidad, la abstracción, la reutilización o la futura integración que nadie pidió todavía. Puede parecer la forma correcta de proceder pero no.
Ya sé que eso puede ser incómodo porque contradice cosas que muchos creemos: decisiones sofisticadas, pensar a futuro, crear un sistema técnico maduro, etc.
A veces la obsesión técnica no te está protegiendo del fracaso.
Te está acercando a él.
Seamos honestos, en esta profesión hay muchas obsesiones que suenan razonables o hasta obligatorias.
La obsesión por que todo sea escalable desde el día uno.
La obsesión por que todo sea genérico.
La obsesión por no duplicar nunca nada involuntariamente.
La obsesión por dejar preparado el sistema para cualquier escenario futuro.
La obsesión por la "arquitectura correcta" antes de que exista suficiente demanda real para justificarla.
Todas tienen algo en común y es que casi siempre nacen de una intención legítima.
Nadie o casi nadie se obsesiona con estas cosas por torpeza. Al contrario. Muchas veces aparecen en equipos inteligentes, con experiencia, que han visto sistemas crecer mal y quieren evitar repetir errores.
El problema es que una preocupación válida puede convertirse en una mala brújula si empieza a dominar todas las decisiones.
Considerar un riesgo técnico está bien, pero organizar el proyecto alrededor de ese riesgo aunque todavía no sea el problema principal es un error.
El daño empieza cuando una obsesión técnica deja de ser una restricción más y se convierte en el centro del diseño.
Ahí empiezan a pasar cosas como estas.
El equipo introduce abstracciones demasiado pronto.
Fragmenta responsabilidades antes de tiempo.
Construye extensibilidad para escenarios hipotéticos.
Añade complejidad operativa en nombre de la escalabilidad.
Diseña APIs pensando más en futuros posibles que en el caso dominante de hoy.
Y el resultado no suele ser un sistema "más preparado".
Suele ser un sistema con más costo cognitivo, más superficie de cambio, más acoplamiento indirecto, menos claridad sobre lo que realmente importa y con un costo monetario altísimo para la mayoría de organizaciones.
Lo peligroso es que, al principio, esta "cultura" no se percibe como algo negativo, al contrario.
Suele verse como sofisticación.
Ese es el truco.
Muchos proyectos empiezan a empeorar justo cuando el equipo siente que está siendo más serio técnicamente.
Entonces la pregunta importante no es si la escalabilidad, la reutilización o la flexibilidad importan.
La pregunta importante es esta:
¿Cuándo una preocupación técnica deja de proteger al proyecto y empieza a deformarlo?
Ahí está la clave, ese es el criterio que mucha gente no formula bien:
Una preocupación técnica empieza a deformar el proyecto cuando su costo presente supera el riesgo real que intenta prevenir.
Ese es el punto de quiebre.
Por ejemplo, pensar en escalabilidad es correcto. Pero si por miedo a crecer introduces una arquitectura distribuida, más latencia, más despliegues, más observabilidad obligatoria, más puntos de falla y más complejidad operacional, cuando aún ni siquiera tienes una presión real de carga, lo que hiciste no fue diseñar mejor.
Fue pagar por adelantado un problema que todavía no tenías.
Es como preocuparte por pagar la cuota de un crédito que no has pedido.
Lo mismo pasa con la reutilización.
Al principio suena noble evitar duplicación. Pero cuando abstraes demasiado pronto, muchas veces no estás capturando una regla compartida. Estás forzando una similitud artificial entre casos que todavía deberían evolucionar separados.
Y eso hace que el sistema pierda claridad.
También pasa con la flexibilidad futura.
Hay equipos que preparan el sistema para diez variantes posibles, múltiples proveedores, motores intercambiables o flujos configurables, cuando el negocio aún no ha validado ni siquiera uno. Lo venden como visión de futuro, pero muchas veces es solo complejidad especulativa.
Y pasa incluso con obsesiones bien vistas en la industria, como performance, clean code, microservicios, event-driven o ciertas formas de DDD.
No porque estén mal.
Sino porque cuando se convierten en un fin y no en un medio, dejan de responder al contexto y empiezan a imponerse sobre él.
El patrón de fondo siempre es el mismo:
Una preocupación técnica sana formula esta pregunta:
"¿Qué necesita este sistema ahora, sin cerrar innecesariamente el futuro?"
Mientras que una obsesión técnica formula otra:
"¿Cómo me protejo desde ya contra todo lo que podría salir mal?"
La primera diseña con proporcionalidad.
La segunda diseña desde ansiedad técnica.
Y esa diferencia puede cambiar el destino del proyecto.
La mayoría de equipos no arruina sus proyectos por no ser suficientemente técnicos.
Los arruina por no saber dosificar ese conocimiento.
Ese es el punto incómodo.
La madurez técnica no consiste solo en conocer más patrones, más estilos o más herramientas.
Consiste en saber cuándo una preocupación técnica merece convertirse en una decisión y cuándo no.
Dicho de otra forma:
No toda decisión técnicamente defendible es arquitectónicamente correcta o aplicable.
Y eso duele un poco aceptarlo, porque implica reconocer que muchas veces la complejidad no viene de la necesidad del sistema.
Viene de nuestra necesidad de sentir que estamos siendo previsivos, rigurosos o sofisticados.
Ahí está el verdadero problema de la obsesión técnica.
No solo agrega complejidad.
Te hace confundir complejidad con madurez.
Si esto es cierto, seguramente varias conversaciones técnicas deberían cambiar.
También las discusiones de arquitectura, porque ya no basta con preguntar si algo escala, si es limpio o si es flexible. También hay que preguntar cuál es el costo actual de optimizar eso y si ese costo está alineado con la demanda real del sistema.
Cambian los code reviews, porque no solo revisas si una solución es elegante, sino si está sobredimensionada para el problema que intenta resolver.
Cambia la forma de priorizar, porque muchas veces el mayor riesgo no es quedarte corto técnicamente.
Es complicar antes de tiempo lo que todavía necesitaba claridad.
Y cambia incluso cómo medimos seniority.
Porque un perfil técnico fuerte no es solo el que conoce más herramientas.
Es el que sabe mantener proporción entre problema, solución y costo estructural.
Si este tema te resonó, cuéntame ¿Cuál es la obsesión técnica que más te ha llegado a afectar? Puedes responder este correo y contármelo.