KISS vs sobreingeniería: el overkill se mata en el pizarrón

Confesión de entrada: cuando me llega una idea, la primera versión casi nunca es simple. Le doy forma, la llevo a brainstorm con el equipo —agentes de IA incluidos, que para esto son entusiastas incorregibles— y el 90% de las veces lo que sale de esa mesa es un esquema por demás complejo, un overkill total para lo que se pretende. Y no lo digo como queja: justo esa es la idea de discutirlo antes. El overkill que muere en el pizarrón cuesta una hora de plática. El que llega a la orden de compra cuesta años.

Después de una década operando infraestructura ajena, esa es mi conclusión menos glamorosa: la sobreingeniería no es un accidente que le pasa a los malos ingenieros; es el estado natural de toda idea. A los ingenieros nos gusta construir, a los vendors les conviene que construyas, y a la IA le encanta proponerte arquitecturas de referencia dignas de un banco. La simplicidad nunca es el punto de partida — es una disciplina que se aplica después, podando.

El overkill más caro se muere por el detalle más chico

Un caso real, de esos que me ha tocado ver en campo (me guardo los nombres). Una consultoría le vendió a una empresa una solución de control de acceso a red (NAC) de las serias: dos appliances físicos en alta disponibilidad, más el manager empresarial virtualizado. Ingeniería de catálogo, del fabricante líder del cuadrante. En papel, impecable.

Nunca pudo hacer NAC. El consultor asumió que, siendo un corporativo grande, la red tendría switching enterprise —Catalyst, Juniper, esa liga—. La realidad en los cuartos de comunicaciones era otra: switches SMB, perfectamente dignos, pero sin la integración que el NAC necesitaba para hacer su trabajo. Toda esa plataforma en HA terminó siendo un portal de visibilidad muy caro: podía ver la red, pero no controlarla.

Fíjate dónde murió el proyecto: no en la solución —el producto es excelente—, sino en una suposición. Nadie fue a ver los switches antes de cotizar. Y ese es el patrón que más se repite en la sobreingeniería de campo: se dimensiona contra la imaginación del entorno («una empresa de este tamaño seguro tiene…») en lugar de contra el entorno real. El diseño más elegante del mundo no sobrevive al inventario que nadie levantó.

Los dos pecados son el mismo error en espejo

Aquí es donde KISS se malinterpreta. Simplificar no es recortar: el enlace único en un sitio crítico, el respaldo que nunca se probó o los dos cables que comparten ducto no son simplicidad — son negligencia con buena prensa. Y en el otro extremo, el clúster de alta disponibilidad para diez usuarios no es robustez — es un pasivo con luces LED.

Los dos cuadrantes rojos de la matriz fallan por lo mismo: la solución se dimensionó contra otra cosa que no era la operación real. Uno le puso de más por vanidad o por suposición; el otro le quitó de más por ahorro mal entendido. La ingeniería está en el ajuste, no en el tamaño. Nosotros hemos armado una WAN full-mesh para una cadena de retail —complejidad seria, cada capa defendida por un riesgo real del punto de venta— y también hemos conectado sitios con una VPN dial-up sobre un internet casero, porque eso era lo que ese sitio necesitaba y ni un peso más. Las dos son la misma filosofía.

El filtro que me regresa a tierra

Cuando estoy cotizando y me tienta el diseño elegante, la pregunta que me desinfla a tiempo es siempre la misma: ¿y esto quién lo mantiene en su año tres? La mantenibilidad a largo plazo es mi filtro número uno, porque la complejidad no se paga el día de la compra — se paga cada madrugada que algo falla y el que está de guardia tiene que entender el sistema para levantarlo. Cada capa que agregas es una capa que alguien tiene que dominar, parchar, documentar y heredar. La deuda técnica también se contrae por exceso, no solo por descuido.

Y va la segunda confesión, la incómoda: yo también traigo camiseta de vendedor. El bundle más completo es el más redituable, y la tentación de ofrecerlo siempre está ahí. Lo que me ha funcionado es ponerme en el lugar del cliente y dimensionar al tiempo de vida planeado de la solución — no a un futuro hipotético que quizá nunca llegue. Si el crecimiento llega antes de lo previsto, qué buen problema: se escala entonces, con datos reales en la mano en lugar de corazonadas. Es la misma lógica por la que a un cliente le recomendamos un VPS con cPanel en lugar de la suite de moda: no porque lo grande sea malo, sino porque lo que no encaja —por arriba o por abajo— siempre sale caro.

Lo simple aguanta más de lo que presume

¿Y el caso inverso? ¿Lo ridículamente simple que lleva años funcionando sin fallar? Lo tengo enfrente todos los días: yo trabajo con Notepad y MS Paint a diario, en serio. Cero plugins, cero actualizaciones que me rompan el flujo, cero sorpresas. No es una postura retro: es que lo que no pusiste no falla, no se parcha y no se mantiene. Esa frase aplica igual a un editor de texto que a una arquitectura de red.

Así que el método, si tuviera que resumirlo: deja que la idea nazca sobrada —va a nacer así de todos modos—, discútela en el pizarrón con gente (y agentes) que propongan de más, y luego poda contra dos preguntas: ¿qué exige de verdad esta operación? y ¿quién mantiene esto en su año tres? Lo que sobreviva a esas dos preguntas, cotízalo. Lo que no, déjalo en el pizarrón, que ahí el overkill es gratis.