“Works on my machine”: qué es, por qué ocurre y cómo prevenirlo

Qué significa “Works on my machine”

“Works on my machine” — una frase que pronuncia un desarrollador cuando un colega o tester reporta un error, pero el error no se reproduce en su máquina. Externamente parece una negación del problema, pero técnicamente la situación es real: el código puede funcionar en un entorno y fallar en otro. Una mínima diferencia en la configuración puede cambiar drásticamente el comportamiento de la aplicación.

La frase se ha convertido en un meme en la comunidad IT porque es a la vez verídica e inútil. Desde la perspectiva del desarrollador, el código realmente funciona en su máquina. Desde la perspectiva del equipo, el problema existe y hay que resolverlo, no justificarlo. El humor radica en que el desarrollador dice la verdad, pero esa verdad no ayuda a corregir el error. El meme es tan popular que se le dedican miles de publicaciones en Reddit, XKCD y conferencias DevOps.

Desde el punto de vista de procesos, la frase “works on my machine” es un indicador de problemas de reproducibilidad del entorno. Si dos desarrolladores no pueden obtener el mismo resultado con el mismo código, el proceso de configuración del entorno no está estandarizado. La práctica DevOps establece que el entorno debe ser reproducible con un solo comando desde el repositorio, sin pasos manuales.

Por qué el entorno local difiere de producción

El entorno local del desarrollador casi siempre difiere de producción. El desarrollador usa macOS o Windows, mientras que el servidor funciona con Linux. Los diferentes sistemas operativos tienen distintos sistemas de archivos, codificaciones, temporizaciones de hilos y llamadas al sistema. Incluso si ambos entornos son Linux, la versión del kernel, glibc y OpenSSL pueden diferir.

La segunda razón es el conjunto de software instalado. La máquina del desarrollador puede tener una instalación global de Node.js 20, mientras que la configuración CI/CD especifica la versión 18. O el desarrollador usa PostgreSQL 16 localmente, mientras que en producción se ejecuta PostgreSQL 14. Las diferencias en versiones menores a menudo pasan desapercibidas, pero las actualizaciones mayores pueden cambiar el comportamiento de las consultas SQL. Según npm Inc., el 67% de los errores relacionados con dependencias son causados por diferencias en versiones patch.

La tercera razón son las condiciones de red. La máquina local no tiene latencia, límites de ancho de banda ni problemas de DNS. En producción, cualquier solicitud a una API externa puede tardar 500 ms en lugar de 5 ms. Timeouts, lógica de reintentos, race conditions — todos estos problemas se manifiestan solo bajo carga real y en condiciones de red reales. La emulación de red mediante herramientas como Toxiproxy ayuda a identificar estos problemas antes del despliegue.

Causas típicas de la no reproducibilidad del error localmente

La primera causa es la falta de datos. El desarrollador trabaja con fixtures de prueba, mientras que en producción hay millones de registros con valores inesperados. NULL en un campo que el desarrollador asumió obligatorio, caracteres Unicode en un nombre, cadenas demasiado largas — todo esto puede causar errores irreproducibles en una base de datos local con datos sintéticos.

La segunda causa son los diferentes flags de compilación y build. Una compilación de lanzamiento (Release/Distribution) puede diferir de una de depuración (Debug). Las optimizaciones del compilador, la eliminación de logs de depuración, la inlineación de funciones — todo esto puede ocultar o, por el contrario, manifestar errores. Un ejemplo típico: un assert funciona en la compilación debug pero falla en release debido a un orden diferente de inicialización de variables.

La tercera causa son la caché local y los archivos temporales. Un desarrollador puede no notar un error porque hay scripts antiguos en la caché del navegador, datos obsoletos en Redis o archivos temporales de ejecuciones anteriores en el sistema de archivos. Una ejecución limpia (modo incógnito, limpieza de caché, instalación fresca) a menudo reproduce el error que no aparecía “por sí solo”.

La cuarta causa son los conflictos entre dependencias globales y locales. Herramientas como Ruby gems, Python pip y Node.js npm pueden tener paquetes instalados globalmente que “ayudan” al código a funcionar localmente pero están ausentes en producción. El uso de entornos virtuales (virtualenv, venv, nvm) aísla el proyecto de las instalaciones globales y hace que el entorno sea repetible.

Impacto en el trabajo en equipo y la confianza

La frase “works on my machine” erosiona la confianza en el equipo. Si un desarrollador no puede reproducir errores regularmente, los colegas comienzan a dudar de su competencia o minuciosidad. Con el tiempo, esto lleva al microgestión: cada cambio requiere verificación de un segundo desarrollador, lo que ralentiza el desarrollo. Según Google Project Aristotle, la seguridad psicológica en un equipo afecta directamente la productividad, y las discusiones constantes sobre el entorno son uno de los factores que la reducen.

El segundo problema es la revisión de código más lenta. Si un desarrollador no puede reproducir un error localmente, puede rechazar el pull request de un colega con las palabras “en mi máquina funciona — entonces el problema es tuyo”. Esto provoca conflictos y retrasa la entrega de funcionalidades. La estandarización del entorno elimina este conflicto: si ambos desarrolladores trabajan en el mismo contenedor Docker, la pregunta de “quién tiene el problema” pierde sentido.

El tercer problema son los errores perdidos en el tracker. Los errores que “no puede reproducir el desarrollador” a menudo se cierran con la etiqueta “Cannot Reproduce”. Un mes después, el error reaparece en producción y su corrección cuesta 10 veces más. La regla: si un error se reproduce al menos para una persona, existe independientemente de si funciona en la máquina del desarrollador o no.

Cómo estandarizar el entorno del desarrollador

El primer y más efectivo método es Docker. Todo el proyecto debe poder ejecutarse con docker-compose up sin pasos adicionales. La base de datos, caché, cola de mensajes, servidor web — todo se levanta en contenedores. El desarrollador solo necesita instalar Docker y Git. Todo lo demás se ejecuta dentro de los contenedores. Esto garantiza que todos los miembros del equipo tengan el mismo entorno independientemente de su SO.

El segundo método son los gestores de versiones. Si Docker no es posible (restricciones de licencia, infraestructura heredada), use nvm (Node.js), rbenv (Ruby), pyenv (Python), sdkman (Java). Los gestores de versiones permiten cambiar las versiones de lenguajes y herramientas por proyecto. Archivos como .nvmrc, .ruby-version, .python-version deben estar en el repositorio y ser verificados por CI/CD.

El tercer método es Vagrant para máquinas virtuales. Vagrant levanta una máquina virtual con un SO y configuración específicos sobre VirtualBox o VMware. Todas las dependencias se instalan dentro de la VM mediante scripts de aprovisionamiento (shell, Ansible, Puppet). Vagrant es más pesado que Docker pero proporciona aislamiento completo a nivel de SO — útil para proyectos que dependen de una versión específica del kernel Linux.

El cuarto método son los Makefile y scripts de bootstrap. Incluso un Makefile simple con objetivos install, test, build, clean puede estandarizar tareas rutinarias. El comando make install debe instalar todas las dependencias, configurar la base de datos y crear datos de prueba. Un único punto de entrada para todos los desarrolladores elimina errores manuales durante la configuración del entorno.

Herramientas para prevenir divergencias de entorno

La herramienta principal son los archivos lock de dependencias. package-lock.json (npm), yarn.lock (Yarn), Podfile.lock (CocoaPods), pubspec.lock (Flutter) fijan las versiones exactas de cada paquete. Sin un archivo lock, dos desarrolladores que instalen dependencias en diferentes momentos pueden obtener versiones menores distintas. El archivo lock debe estar en el repositorio y no editarse manualmente.

La segunda herramienta es .env.example en el repositorio. Un archivo plantilla para variables de entorno con comentarios. El desarrollador lo copia a .env y completa sus valores. El pipeline CI/CD verifica que todas las variables obligatorias estén definidas. Según GitLab 2023, los equipos que usan .env.example reducen los incidentes relacionados con variables de entorno en un 40%.

La tercera herramienta son los hooks de pre-commit. Comprobaciones automatizadas que se ejecutan antes de cada commit: linter, formateador, verificación de tipos, tests. Si los hooks están configurados idénticamente para todos los desarrolladores, los errores de formato o tipos que “pasaron localmente” no llegarán a producción. Husky para JavaScript y pre-commit para Python son soluciones populares.

La cuarta herramienta es un pipeline CI/CD que ejecuta tests en un entorno limpio. Si los tests pasan en CI pero fallan localmente, el problema está en la configuración del entorno local. Si los tests fallan en CI, el pull request no se fusiona. Esta regla estricta evita que errores que “funcionan localmente” lleguen a la rama principal.