La navaja de Ockham y el código: contra la abstracción prematura

En el siglo XIV, Guillermo de Ockham formuló un principio que sobrevivió a siete siglos: no multipliques las entidades sin necesidad. Era una regla de metafísica, no de software. Pero describe con una precisión incómoda el error más caro que cometemos los developers: abstraer antes de que haga falta.

El principio, tal cual

La navaja de Ockham no dice “lo simple es bonito”. Dice algo más fuerte: entre dos explicaciones que dan cuenta de los mismos hechos, la que introduce menos entidades es preferible. No por gusto estético, sino porque cada entidad extra es una afirmación más que puede estar equivocada.

En código, cada capa de abstracción es una entidad. Cada interfaz, cada factoría, cada capa de indirección es una afirmación sobre el futuro: “esto va a variar de estas formas”. Y como toda afirmación sobre el futuro, casi siempre es falsa.

La abstracción es una apuesta, no un regalo

Existe la idea de que abstraer siempre es virtud —que un código con muchas capas es “más profesional”. Es al revés. Abstraer es apostar.

Cuando creas una interfaz PaymentProvider con una sola implementación, estás apostando a que algún día habrá varias. Si aciertas, te ahorras un refactor. Si fallas —y fallas la mayoría de las veces— has pagado un impuesto permanente: cada developer que lea ese flujo tendrá que saltar por una indirección que no protege de nada.

La abstracción correcta se paga sola. La abstracción prematura la paga el que la mantiene, todos los días, para un futuro que no llegó.

YAGNI es Ockham aplicado

El acrónimo YAGNI —“You Aren’t Gonna Need It”— es la navaja de Ockham traducida al gremio. No construyas para el requisito que imaginas; construye para el que tienes delante.

La objeción típica: “pero si lo dejo preparado, luego es más fácil”. Casi nunca. El coste de añadir una abstracción cuando de verdad hace falta —cuando ya conoces las dos o tres formas reales en que varía— es menor que el coste de mantener una abstracción especulativa que adivinó mal las variaciones. El futuro conocido es barato de abstraer. El futuro imaginado es caro de sostener.

Cómo distingo una capa necesaria de una prematura

• ¿Cuántas implementaciones reales tiene hoy? Una interfaz con una sola implementación no es una abstracción: es un adorno con coste de lectura.
• ¿La variación ya ocurrió, o la estoy imaginando? Abstraer sobre variación observada es diseño. Abstraer sobre variación imaginada es adivinación.
• ¿Puedo introducirla después sin dolor? Si extraer la abstracción el día que haga falta cuesta media hora, no la construyas hoy. Espera al día.
• ¿Esta capa protege de algo, o solo mueve el problema una casa más allá? La indirección que no aísla nada solo añade un salto más a la lectura.

La regla de las tres veces

Hay una heurística vieja que sigue rindiendo: no abstraigas hasta la tercera repetición.

La primera vez, escribes el código. La segunda vez que aparece algo parecido, lo duplicas —sí, a propósito— y aguantas la incomodidad. Solo a la tercera, cuando ya ves la forma real de lo que se repite, extraes la abstracción. Para entonces no estás adivinando el patrón: lo estás leyendo de tres casos concretos.

Duplicar dos veces es más barato que mantener durante dos años una abstracción que adivinó mal. La duplicación prematura se borra en cinco minutos; la abstracción prematura echa raíces.

El coste que no se ve en el diff

Lo que hace peligrosa a la abstracción prematura es que no aparece como problema. Un diff con más interfaces, más capas y más ficheros parece trabajo serio. Nadie te va a rechazar un PR por estar “demasiado bien estructurado”.

Pero el coste llega después, disperso, imposible de atribuir: la persona que tarda el doble en seguir un flujo simple, el bug que se esconde tres capas abajo, el cambio trivial que hay que tocar en cinco sitios porque la abstracción repartió una decisión que debería haber vivido junta.

Por qué me importa

La filosofía me enseñó a desconfiar de las entidades que introduzco para explicar algo. Cada concepto nuevo tiene que ganarse el sitio: si puedo dar cuenta de los mismos hechos sin él, sobra.

El código es igual. La elegancia no está en la cantidad de capas que sostienes, sino en la cantidad que conseguiste no necesitar. Un sistema es maduro no cuando ya no puedes añadirle nada, sino cuando ya no puedes quitarle nada sin romperlo.

La navaja de Ockham, siete siglos después, sigue siendo el mejor consejo de arquitectura que conozco: cuando dudes entre dos diseños, quédate con el que introduce menos cosas que puedan estar equivocadas.