No es un error, es una característica — significado, origen y diferencias

Qué significa “No es un error, es una característica”

“No es un error, es una característica” — una frase con la que un desarrollador o gerente indica que un comportamiento inesperado del programa es intencional, no erróneo. En el caso clásico, es una broma: todos entienden que el comportamiento es incorrecto, pero lo llaman “característica” para aliviar la tensión. Sin embargo, en proyectos reales, la frase también se usa en serio — cuando el comportamiento realmente coincide con la especificación pero no cumple con las expectativas del usuario.

La diferencia entre un error y una característica suele ser subjetiva. Para un desarrollador que escribió el código, cierto comportamiento puede parecer lógico. Para un usuario, puede parecer inesperado y erróneo. La subjetividad de la percepción es la razón principal por la que la frase es tan persistente. Permite pasar la conversación de “quién tiene la culpa” a “así fue diseñado”. Según UX Collective, el 40% de los errores reportados por los usuarios son en realidad problemas de UX, no errores de código.

En los equipos ágiles, la frase se usa a menudo como mecanismo de defensa durante las demos. El desarrollador muestra un comportamiento inesperado, el product owner frunce el ceño y se escucha la fatídica frase “no es un error, es una característica”. La confianza en el equipo determina si la frase se toma como una broma o como un intento de ocultar un problema. En un equipo saludable, esa broma alivia la tensión; en uno tóxico, provoca conflictos.

Historia de la frase icónica

El primer uso conocido de la frase se registró en 1976 en un boletín de DECUS (Digital Equipment Corporation User Society). Un usuario se quejaba de que el procesador de textos RUNOFF manejaba incorrectamente las líneas en blanco. La respuesta del desarrollador: “No es un error, es una característica — así se procesan los párrafos”. Desde entonces, la frase se ha convertido en un símbolo de defender el código escrito “tal cual”, independientemente de su calidad real.

La frase ganó popularidad gracias al Jargon File — un diccionario de jerga hacker que en la década de 1990 sirvió de base para el libro “The New Hacker’s Dictionary”. En el Jargon File, la entrada “feature” se refiere directamente a errores que se convirtieron en características porque era imposible o no se deseaba corregirlos. Ejemplo: la tecla Bloq Mayús en los terminales antiguos no tenía indicador luminoso — esto era un error que se convirtió en una característica “para escritura a ciegas”.

En la década de 2000, la frase pasó a la cultura popular a través de los memes de internet. Una imagen de un gato con el texto “It’s not a bug, it’s a feature” se difundió por foros y redes sociales. En la industria de los videojuegos, la frase se usa con especial frecuencia: los fallos que no afectan la jugabilidad se declaran “características” por el ambiente. El fenómeno cultural se ha extendido mucho más allá de la TI — la frase se puede escuchar en cualquier contexto donde se excuse un error.

Psicología de la excusa: por qué se dice

La base psicológica de la frase es la disonancia cognitiva. Un desarrollador ha pasado horas escribiendo código, y admitir que el resultado es erróneo significa devaluar su trabajo. La frase “no es un error, es una característica” reduce la disonancia: el error se convierte en una decisión deliberada, y el desarrollador pasa de ser el culpable a ser el autor de la idea. Es un mecanismo de defensa psicológica que preserva la autoestima.

La segunda razón es el miedo a la repetición del trabajo. Admitir un error significa volver a pasar por revisión de código, pruebas e implementación. Una “característica” no requiere corrección — la tarea se cierra, la carga de trabajo disminuye. Según Microsoft Research, los desarrolladores minimizan deliberadamente la gravedad de los errores para evitar repeticiones en el 23% de los casos. La frase es una forma leve de esa minimización.

La tercera razón es la cultura corporativa. En algunas empresas, los errores afectan los KPI del desarrollador, y encontrar un error en la revisión de código se considera un fallo del autor. En ese entorno, la frase “no es un error, es una característica” es una forma de evitar consecuencias negativas para la carrera. Una cultura de error saludable (blameless culture) elimina esta causa: si los errores no se castigan, es más fácil admitirlos.

Dónde está la línea entre un error y una característica

Existe un límite claro solo cuando hay Criterios de Aceptación. Si el comportamiento no coincide con ningún punto de los CA — es un error. Si el comportamiento coincide con los CA pero al usuario no le gusta — es un problema de UX, no un error. Si no hay CA — cualquier comportamiento puede declararse característica, y esta es la razón principal de la persistencia de la frase.

Una regla práctica: un error es cuando un programa hace algo que no debería, o no hace algo que debería, según la especificación. Una característica es cuando un programa hace lo previsto, incluso si el resultado sorprende al usuario. Casos dudosos: comportamiento indefinido (el lenguaje no define el resultado), condiciones de carrera (se manifiestan de forma intermitente), casos extremos (funciona para el 99% de los datos).

Para mayor claridad, use una matriz de decisiones:

• El comportamiento está descrito en la especificación e implementado correctamente — característica, incluso si no le gusta
• El comportamiento está descrito pero implementado incorrectamente — error, necesita corrección
• El comportamiento no está descrito pero se deduce lógicamente de los requisitos — característica no documentada, debe añadirse a la especificación
• El comportamiento no está descrito y no es lógico — error, los requisitos necesitan aclaración

El caso más peligroso es cuando no hay especificación y el desarrollador decide por sí mismo qué es una característica. En tales proyectos, cualquier error puede declararse “característica”, lo que hace que el código sea impredecible para todo el equipo. Unos Criterios de Aceptación claros para cada tarea — la única forma de trazar la línea de manera objetiva.

Por qué es peligrosa la confusión de conceptos en el equipo

El primer peligro es la erosión de la calidad. Si cada error puede declararse característica, el equipo no tiene incentivos para escribir código de calidad. Los errores dejan de corregirse, la deuda técnica crece y los usuarios se acostumbran al “comportamiento extraño”. Tarde o temprano, un competidor lanza un producto que funciona de manera predecible y los usuarios se van.

El segundo peligro es el conflicto en el equipo. Un ingeniero de QA encuentra un error, un desarrollador dice “es una característica”. Sin criterios objetivos (Criterios de Aceptación), la discusión se vuelve personal: “tú pruebas mal” vs “tú programas mal”. Según PractiTest State of Testing 2023, las disputas “error vs característica” son una de las tres principales causas de fricción entre QA y desarrolladores.

El tercer peligro son los riesgos legales. En industrias reguladas (medicina, finanzas, aviación), los conceptos de “error” y “característica” tienen peso legal. Si en un software médico un comportamiento se declara característica pero provoca un cálculo incorrecto de dosis — no es una broma, es una infracción regulatoria. Los sistemas críticos para la seguridad no toleran la sustitución de conceptos, por lo que siempre utilizan verificación formal.

Cómo evitar la confusión entre un error y una característica

La herramienta principal son unos Criterios de Aceptación claros en cada tarea. Los CA se escriben antes de comenzar el desarrollo: “Al ingresar X, el sistema debe devolver Y”. Si el comportamiento no está descrito — es un error por defecto, incluso si el desarrollador piensa lo contrario. Los CA deben ser medibles y verificables: “el botón es verde” es malo, “HEX #00FF00” es bueno.

La segunda herramienta es una Definición de Hecho en el equipo. Una descripción clara de lo que significa “tarea terminada”: código escrito, pruebas escritas, pruebas superadas, revisión de código completada, implementado en staging, probado por QA. Si todos los puntos de la Definición de Hecho se cumplen y el usuario aún se queja — no es un error, sino un requisito omitido que va al backlog como una nueva característica.

La tercera herramienta es una cultura de análisis post-mortem sin culpa. Si un error fue declarado característica y llegó a producción — analizamos las causas, no buscamos culpables. ¿Por qué el desarrollador pensó que era una característica? ¿Por qué QA lo pasó por alto? ¿Por qué los CA estaban incompletos? Las respuestas a estas preguntas mejoran el proceso, no castigan a las personas. Las mejoras sistémicas funcionan mejor que prohibir la frase “no es un error, es una característica”.