Principio de mínima sorpresa

Un componente de un sistema debe comportarse de la manera que la mayoría de los usuarios espera, sin sorprenderlos.

También llamado “Principle of Least Surprise” (POLA / POLS).

Origen

La idea circula desde finales de los 60 en la documentación interna del lenguaje PL/I de IBM, llegó a la comunidad de CLU y Smalltalk en los 70, y la popularizó como aforismo Geoffrey James en The Tao of Programming (1987), un librito en estilo zen con observaciones sobre el oficio. La frase es un principio de diseño de interfaces (humanas y máquina-máquina): cada vez que un sistema se comporta de modo distinto al que un usuario razonablemente esperaría, gasta crédito — confianza, atención, tiempo de soporte. Suficientes sorpresas, y el sistema deja de usarse, aun siendo correcto.

Ejemplo

La sorpresa más cara del software: un atajo de teclado destructivo sin confirmación. Ctrl+Z deshace, todos lo saben. Pero hay aplicaciones donde Ctrl+Z en cierto modo deshace la acción y en otro borra el documento entero. Vas a perder usuarios, no por el bug, sino por la violación de la expectativa.

Otros casos típicos:

• Un botón que dice “Cancelar” pero también guarda los cambios pendientes.
• Una API que devuelve 200 OK con un cuerpo {"error": "..."} en lugar de un código 4xx/5xx.
• Un comando CLI cuya flag --force significa una cosa, y la flag -f significa otra distinta.
• Un toggle que dice “Desactivar notificaciones” pero las activa en otro canal.
• Una función que se llama getUser() y, además de leer, inserta un row en una tabla de auditoría.

El test mental — barato y útil — es escribir el comportamiento en una frase y leerla en voz alta a alguien que no escribió el código. Si pone cara rara, el sistema sorprende. Cara rara = bug de diseño, aunque la implementación sea correcta. Las sorpresas que el equipo “ya sabe” son las que más costo tienen, porque se exportan al usuario que no las sabe.