← Glosario Concepto

Ley de conservación de la familiaridad

También: Law of Conservation of Familiarity

  • processes
  • release-train
  • team-structure
  • migrations
  • culture

Cada cambio en un sistema de software reduce la familiaridad del equipo y los usuarios con él, y aumenta la curva de aprendizaje.

Origen

Es una de las ocho “leyes de evolución del software” del ingeniero austríaco-británico Manny (Meir) Lehman, formuladas en una serie de papers entre 1974 y 1996 mientras dirigía el Programming Research Group en el Imperial College London. Lehman estudió la evolución a largo plazo de sistemas grandes (originalmente OS/360 en IBM) y descubrió que el software no se comporta como una máquina: tiene patrones de evolución más parecidos a los organismos vivos. Sus ocho leyes describen lo que pasa con los “E-type systems” (los que dependen del mundo real y por lo tanto deben cambiar permanentemente para seguir siendo útiles).

La de la conservación de la familiaridad dice, en esencia: cada release nuevo introduce conocimiento que no estaba antes en la cabeza del equipo ni del usuario. Si los releases vienen demasiado rápido, la cantidad acumulada de cosas-no-aprendidas explota y la velocidad efectiva del equipo cae — aunque el commit log diga lo contrario.

Ejemplo: el equipo que “está muy productivo” hasta que ya nadie sabe nada

Es la ley que justifica los release trains y los changelog claros. Si un equipo de plataforma cambia tres convenciones internas por trimestre sin documentar, el equipo de producto tarde o temprano deja de entender la plataforma — aunque cada cambio individual fuera “una mejora”. Lo mismo le pasa al usuario final: una app que rediseña la UI cada dos meses tiene métricas de engagement que se desploman, no porque el rediseño sea malo, sino porque cada rediseño gasta familiaridad acumulada.

El corolario operativo es mantener un ritmo de cambio sostenible y bien comunicado. No es “no cambiar”; es saber que cada cambio tiene un coste cognitivo distribuido entre toda la organización, y presupuestar ese coste. Cuando alguien dice “este refactor es transparente, nadie lo va a notar”, casi siempre se equivoca: alguien lo va a notar, y la cuenta la paga el equipo entero.

Conceptos relacionados

Una idea por semana, contada con una historia

Si te sirvió, seguro te sirve el resto. Recorré el glosario o escribime qué concepto te falta.