Cuando «funciona en mi equipo» no significa que funcione
Una aplicación funcionaba perfectamente hasta que salió del computador donde fue creada. Un pequeño fracaso que terminó revelando una diferencia importante entre construir algo que funciona y construir algo que realmente pueda usar otra persona.
Hay una frase que probablemente todo programador ha pronunciado alguna vez:
—Pero en mi equipo funciona.
Y casi siempre es el comienzo de un problema.
Hace poco estaba trabajando en una pequeña aplicación que debía cumplir una condición bastante simple: ser portable. No portable en el sentido técnico de la palabra, sino en el sentido humano.
Copiar. Ejecutar. Usar.
Nada de instalar Python, buscar librerías, abrir una consola o explicarle a alguien qué es una dependencia.
En mi computador funcionaba perfectamente.
Preparé el ejecutable, lo probé varias veces y todo parecía terminado. Hasta que lo llevé a otro equipo.
Error.
La primera reacción fue buscar qué estaba fallando en ese computador. Quizás una versión de Windows, algún permiso, una configuración particular.
Pero el problema no estaba allí.
Estaba en mi definición de portable.
Yo había construido una aplicación capaz de ejecutarse en mi entorno. El usuario, en cambio, necesitaba una aplicación capaz de llevar consigo su propio entorno.
Parece una diferencia pequeña.
No lo es.
La solución fue empaquetar dentro de la distribución todo aquello que el programa necesitaba para funcionar. El resultado ocupaba más espacio y era menos elegante desde cierta mirada técnica.
Pero era mucho más correcto.
Porque el objetivo nunca había sido construir el ejecutable más pequeño.
El objetivo era que alguien pudiera hacer doble clic y usarlo.
El usuario no debería completar nuestra arquitectura
A veces desarrollamos pensando que una instrucción sencilla también será sencilla para quien está al otro lado.
«Instala esta librería».
«Configura esta variable».
«Ejecuta este comando».
Para nosotros pueden ser treinta segundos. Para otra persona pueden significar que el programa simplemente no funciona.
Y ahí hay una idea que intento recordar cada vez con mayor frecuencia:
Una solución no está terminada cuando funciona en el computador donde fue construida. Está terminada cuando funciona en el computador de la persona para quien fue construida.
Quizás esa sea una de las partes menos visibles de desarrollar software.
No basta con resolver el problema.
También hay que conseguir que la solución llegue completa hasta el otro lado.