El coste del mal nombramiento en software: el ‘impuesto cognitivo’ de nombres poco descriptivos

Por qué importan los nombres en ingeniería

Durante décadas, distintas ingenierías han seguido un principio simple: un nombre debe ayudar a entender la función, la forma o el propósito de un objeto. En química, medicina o ingeniería civil la nomenclatura no es un ejercicio estético sino una herramienta de comunicación técnica; cuando falla, se paga en seguridad, en tiempo y en errores de interpretación. La máxima de Confucio —“es necesario rectificar los nombres”— sigue siendo relevante: si las palabras no son eficaces, los asuntos se enredan.

En el primer software la norma era similar: utilidades como grep, sed, diff o cat y lenguajes como FORTRAN, COBOL o SQL transmitían, aunque fuera mediante siglas o abreviaturas, una pista sobre su propósito. Ese tipo de nombres reducen la carga cognitiva y facilitan la transmisión de conocimiento dentro de equipos y comunidades.

La deriva en el ecosistema del software

En los últimos años ha emergido una tendencia inversa. Tal y como apunta el programador Salih Muhammed y recogen debates públicos, el ecosistema actual está lleno de librerías, herramientas y servicios con nombres evocadores pero opacos: animales, dioses nórdicos, metáforas crípticas o palabras sin relación aparente con la función real. Ejemplos contemporáneos en descripciones técnicas —»Usamos Viper para la configuración, Cobra para la línea de comandos, Melody para los WebSockets, Casbin para permisos y Asynq para las colas de trabajo»— ilustran el problema: el oyente debe detenerse y mapear cada nombre a su función.

Dos factores han alimentado esa deriva: el auge de la cultura startup, donde una marca distintiva puede ser un activo de marketing, y la multiplicación de proyectos de código abierto en plataformas públicas. Un paquete con un nombre llamativo puede destacar en búsquedas, pero no siempre ayuda a quien, sin contexto, necesita entender rápidamente qué hace una dependencia.

El debate: nostalgia, escala y buscabilidad

No todo el mundo considera que haya existido una “edad dorada” de buenos nombres. En foros como HackerNews se recuerda que muchos nombres históricos del software tampoco eran transparentes: GNU es un acrónimo recursivo, awk proviene de las iniciales de sus autores y dd tiene un origen ambiguo. La familiaridad con un nombre suele construirse con el uso continuado; un nombre se vuelve útil por costumbre tanto como por claridad intrínseca.

Además hay un argumento práctico: la buscabilidad. En un mundo dominado por buscadores y modelos de lenguaje, un nombre genérico como http-client es descriptivo pero difícil de posicionar; un nombre único facilita que los usuarios encuentren documentación y ejemplos. Esto explica por qué muchos autores optan por palabras distintivas aun a costa de precisión semántica.

Implicaciones prácticas para desarrolladores y equipos

El problema no es puramente estético: cuando los nombres fallan, el coste es real y acumulativo. Algunos impactos concretos:

• Onboarding más lento: nuevos miembros de equipos pierden tiempo asociando dependencias a funcionalidades.
• Mayor carga cognitiva diaria: durante un proyecto moderno con decenas o cientos de dependencias, pequeños segundos para identificar cada paquete se suman.
• Fricción en la comunicación: en revisiones de código, documentaciones y reuniones, los nombres que no sugieren su función obligan a explicaciones adicionales.
• Problemas de descubrimiento: herramientas difíciles de buscar pueden quedar ocultas pese a ser útiles.

Para los responsables técnicos y líderes de equipo, la recomendación práctica es establecer convenciones de nombrado y revisar nombres como parte del control de calidad del código y la documentación. Algunas pautas concretas útiles para proyectos y mantenedores:

• Priorizar nombres descriptivos: combinar un término claro (p. ej., queue, auth, cache) con un sufijo o prefijo si hace falta para singularidad.
• Usar namespaces y scopes de empaquetado (por ejemplo, @organizacion/mi-paquete) para evitar colisiones y mantener contexto.
• Incluir en el README una primera línea explícita que defina la función primaria del proyecto (“Librería X: cliente HTTP asíncrono para …”).
• Documentar alias o nombres de CLI si el binario difiere del nombre del paquete.
• Adoptar una política de revisión de nombres en pull requests y en el proceso de publicación.
• Balancear marketing y claridad: si se opta por un nombre de marca, compensar con metadatos, etiquetas y buena documentación para la buscabilidad.

Riesgos, implicaciones y recomendaciones adicionales

Más allá de la incomodidad cognitiva, hay riesgos prácticos asociados a una mala estrategia de nombres:

• Confusión y errores humanos en cadenas de dependencias complejas: nombres que no transmiten función aumentan la probabilidad de incorporar dependencias inapropiadas o redundantes.
• Dificultades en auditorías y revisiones de seguridad: identificar rápidamente qué hace cada componente es clave en procesos de seguridad y cumplimiento.
• Coste acumulado a largo plazo: el tiempo invertido en descifrar etiquetas es tiempo no dedicado a resolver problemas reales ni a diseñar soluciones.

Para mitigar estos riesgos conviene combinar medidas organizativas y técnicas:

• Convenciones internas de nombre y metadatos: exigir descripciones claras en los manifiestos de paquetes (package.json, pyproject.toml, etc.).
• Categorías y tags en repositorios públicos para mejorar la búsqueda y el descubrimiento.
• Prácticas de documentación mínima obligatoria: “qué hace”, “para qué usarlo” y “ejemplo mínimo” en la primera sección del README.
• Revisión periódica de dependencias: auditar por función y utilidad para eliminar ruido y redundancias.

Conclusión

El nombre de una herramienta o librería no es solo una etiqueta estética: es una pieza de interfaz pública que afecta el tiempo de incorporación, la claridad de la comunicación y la mantenibilidad de proyectos. La tensión entre marcas distintivas y nombres descriptivos es real y está ligada a factores culturales (startup, marketing) y técnicos (volumen de proyectos, buscadores).

Para reducir el llamado “impuesto cognitivo” conviene adoptar convenciones de nombrado, documentar de forma mínima y explícita, y equilibrar la necesidad de singularidad con la obligación de que un nombre ayude, no obstaculice, a entender qué hace un componente. Es una mejora de proceso simple que devuelve tiempo y reduce fricción en equipos y comunidades de desarrollo.

Source: www.genbeta.com