Complejidad inútil: el precio del «por si acaso»

La complejidad inútil casi nunca nace de una mala intención. Nace de una buena: «por si necesitamos varias bases de datos», «por si conectamos otro proveedor», «por si el equipo crece». Cada «por si acaso» añade una capa. Y cada capa se paga — no el día que se escribe, sino todos los días siguientes.

El coste es diario, el beneficio es hipotético

Una abstracción «por si acaso» se lee en cada debug, se rodea en cada evolución, se explica en cada incorporación. El escenario que prepara, en cambio, muchas veces nunca llega — o llega con una forma que la abstracción no había previsto, y hay que deshacerla igualmente.

Tres preguntas para filtrar

Ante una capa existente o una que estás a punto de escribir: ¿la usa hoy un caso real? Si la quitaras, ¿qué se rompería concretamente? ¿La persona que lea este código dentro de un año entenderá por qué existe sin que se lo expliquen? Tres «no» = una capa que quitar.

La sobriedad no es ingenuidad

No se trata de escribir código simplista que ignore las necesidades reales. Se trata de esperar a que la necesidad exista antes de pagarla. Un sistema sobrio puede acoger complejidad — cuando la justifica un caso real, se integra limpiamente. La que pudre es la complejidad especulativa: estructura el código alrededor de escenarios imaginarios.