Hago clic... ¡y no pasa nada!

Todos (bueno, todos los de este lado de la brecha digital) sentimos con cierta frecuencia esta sensación de desazón que nos invade cuando estamos intentando realizar cualquier operación por Internet, hacemos clic para validar una opción y pasados unos cuantos segundos ... ¡no pasa nada!. De repente, nos invade el temor porque no sabemos si esa transferencia se ha realizado o no, si nos cargarán o no ese importe en la tarjeta de crédito, si el pedido es o no conforme... No tenemos nada en nuestra mano que nos garantice la veracidad de los hechos.

(Fuente: redusers)

Tendremos que empezar a revisar los cargos de la VISA, el saldo de la cuenta, o lo que sea para intentar averiguar dónde y en qué punto se rompió esa relación cordial con nuestro ordenador, con la Red, con otros cientos de ordenadores que ignoramos dónde están y para qué sirven, y con el ordenador de nuestro Banco, proveedor, o lo que sea.

El origen de este problema radica en que estamos rodeados de cientos, de miles de aplicaciones y programas informáticos, imbricados en equilibrios muchas veces inestables, y las cosas sólo acabarán funcionando bien cuando toda la cadena completa de ordenadores, aplicaciones y programas funcione de acuerdo a lo que esperamos de ellos, cuando todos los engranajes funcionen a la perfección.

Un antiguo y llorado colega, Francesc Lluch, informático de la vieja escuela donde los hubiera, solía decir, para ilustrar el éxito, que había escrito un programa que sabía contar hasta 100 y se paraba. Con ello quería ilustrar una realidad que debería ser de cabecera para cualquiera que se dedique, de una u otra forma, a la informática: el coste (en tiempo, por ejemplo) de desarrollar un programa que haga lo que queremos que haga cuando le suministramos los datos que espera no es más que un 10% (si acaso) del coste de hacer un programa sólido que haga lo que queremos que haga en cualesquiera circunstancias.

Esto era cierto cuando las aplicaciones y programas informáticos eran piezas muy homogéneas y sólidas que funcionaban sobre un ordenador, preparados para ser utilizados por usuarios formados y entrenados. Con el paso del tiempo y la extensión de las telecomunicaciones en sentido amplio, las aplicaciones y programas se tuvieron que desarrollar pensando en que debían poder ser utilizados por cualquier usuario, incluso por el público en general. Sólo este hecho supone que en el desarrollo del código de programas y aplicaciones hay que tener en cuenta un catálogo casi infinito de barbaridades que puede cometer el usuario y que en ningún caso deben provocar un malfuncionamiento: tienen que estar previstos.

Con la extensión prácticamente universal de Internet, y su utilización por todo tipo de usuarios, este fenómeno se ha agudizado por varios motivos. Los que antes eran programas monolíticos, ahora son un conjunto de piezas separadas, que funcionan en diversos ordenadores, incluyendo el del propio usuario, de los que el programador poco o nada sabe cuando escribe su código. Las aplicaciones se han convertido en engranajes muy complejos, que deben funcionar a la perfección en cualesquiera circunstancias.

Esquema simplificado del funcionamiento de aplicaciones
monolíticas centralizadas. Un mundo cerrado.
(Fuente: jmscaos)

Tradicionalmente, la estructura de la profesión informática incluía a programadores, analistas e ingenieros de sistemas que, progresivamente al desplazarse hacia arriba en la pirámide, tenían una perspectiva mayor del sistema en su conjunto. Pero la labor del programador era muy importante y de gran responsabilidad. Debían desarrollar y depurar el código para que ese programa o aplicación realizara el proceso que se esperaba de él, a partir de los datos que se le suministraran. El analista debía definir cuáles (y cómo) eran los datos de entrada a ese programa, y lo mismo para los de salida. El control de calidad del programador debía incluir la verificación de que el código desarrollado cumplía con las especificaciones definidas. Y prácticamente se podían integrar los programas desarrollados por todo un equipo de programadores para tener una aplicación o un sistema informático que funcionara de acuerdo a lo que se esperaba de él.

Con la evolución de las tecnologías y la progresiva modularización de la programación, el control de calidad del trabajo del programador garantizaba en menor medida la adecuación de la aplicación global a las especificaciones definidas. Para empezar, había un factor de escala. No era para nada lo mismo que el código se probara con un usuario  y una base de datos de prueba con cien registros, por ejemplo, a un funcionamiento más realista, donde hubiera cientos o miles de usuarios simultáneos (en la práctica, cientos o miles de instancias del mismo código, ejecutándose simultáneamente sobre el mismo ordenador), trabajando todos contra una misma Base de Datos de millones de registros. Hubo que desarrollar las buenas prácticas necesarias para poder garantizar que el trabajo de los programadores fuera compatible con ese factor de escala, y no aparecieran en la fase de pruebas limitaciones inaceptables que provocaran la necesidad de un rediseño de todo el conjunto. Apareció un oficio nuevo, el arquitecto de aplicaciones. Este debía mantener la perspectiva del edificio completo (la aplicación en su conjunto) y asegurar que lo desarrollado en el sótano y en los diferentes pisos fuera compatible y conforme, para alcanzar finalmente un edificio de calidad.

Pero la extensión de Internet ha generalizado el desarrollo de lo que se acostumbra a llamar aplicaciones web, que son las que utilizamos todos continuamente, aunque no siempre seamos conscientes de ello. Su característica diferencial es la casi infinita atomización de los módulos de programa, cada uno limitado a una función específica. Esto ha provocado, paralelamente, una degradación de la posición del programador en la pirámide del oficio. Lo que ha llevado, obviamente, a que sea una labor muy mal pagada, realizada habitualmente por los más junior del oficio, de la que cualquiera con ambición y talento huye en cuanto puede. Lógicamente, la calidad del código entregado por los desarrolladores también se ha resentido.

En paralelo, ha habido que desarrollar nuevas labores en la pirámide del oficio. Ha aparecido, por ejemplo, el urbanista de aplicaciones. Porque ya no se trata de construir un edificio, sino de crear una ciudad coherente y habitable. Con sus zonas residenciales, comerciales y de ocio; cada una con sus comportamientos y exigencias específicos.

Un esquema simplificado de aplicación web, con
los diversos ordenadores y módulos involucrados.
(Fuente: brainlabs)

Tomemos un ejemplo: una aplicación bancaria para los clientes de Banca Online, que requiera autenticación del usuario mediante contraseña o cualquier otro método. En el interior de la aplicación habrá un elevado número de módulos de programa, cada uno dedicado a una tarea concreta: conexión y desconexión del usuario, visualización de su posición global, realización de una transferencia (posiblemente haya transferencias de muchos tipos diferentes, que requieran cada una de un proceso específico), compra o venta de valores, etc. etc. Todos estos módulos funcionarán sobre diversos ordenadores del Banco, cuyo número y naturaleza habitualmente se desconoce en la fase de escritura del código. Por lo tanto, es necesario que el código sea portable y escalable.

Cada módulo podrá ejecutarse en condiciones de entorno diferentes. Un usuario debe poder ver su Posición Global y desconectarse, mientras otro querrá realizar una transferencia y luego desconectarse, o incluso ordenar una compra de valores y desconectarse a continuación. La visibilidad para el usuario será que, haga lo que haga, dispondrá en la pantalla de una opción de desconexión. Que, en todos los casos, debe lanzar la ejecución del módulo de desconexión correcto. Porque las aplicaciones, como las ciudades, son seres vivos. Continuamente se construyen (o derriban) edificios de viviendas en la zona residencial, se abren (o cierran) comercios en la zona comercial, se abren (o cierran) restaurantes o cines en la zona de ocio. El residente deberá modificar sus hábitos y costumbres para adecuarse a esos cambios.

Si un residente se empeña en ir a comprar el pan a un comercio que ya cerró, Houston, tenemos un problema. Si un comercio dejó de vender pan pero no cerró, y muchos residentes siguen yendo allí para comprar pan, tenemos un problema también.

En las aplicaciones web, además, existe un factor añadido de complejidad técnica. Parte del código de la aplicación se interpreta y ejecuta en el propio ordenador del usuario, en el seno de lo que se conoce como Navegadores (o browser, en inglés). Y no podemos obviar el hecho de que el dispositivo de acceso del usuario a la aplicación puede ser, a su vez, de diferentes categorías: ordenador (con diferentes tamaños de pantalla y diversas resoluciones), tablet, smartphone, etc. En algunos casos deberá existir una versión específica de la aplicación para cada tipo de dispositivo de acceso. No se organiza igual un McDonalds que un McAuto, por ejemplo.

Incluso si el dispositivo es un PC en todos los casos, el Sistema Operativo puede ser de diversos tipos (Windows, Linux) y de diversas versiones. Y existen, también, varios Navegadores diferentes bien implantados en el mercado. Los tres más extendidos en la actualidad son el Internet Explorer, el Google Chrome y el Mozilla Firefox, pero hay bastantes más. Todos los Navegadores hacen exactamente lo mismo, pero no necesariamente de la misma manera. Por lo tanto, inevitablemente, no se comportarán todos exactamente del mismo modo al interpretar un código que le envíe la aplicación del Banco.

Para la aplicación de ese Banco que estábamos comentando, el número de combinaciones posibles es prácticamente infinito. Y nunca va a ser posible haber probado exhaustivamente todas ellas.

Analizada toda la intrincada complejidad interna, volvamos a ese usuario desconcertado, que ha hecho clic y no ha pasado nada. Ha proporcionado todos los datos necesarios para realizar una transferencia, por ejemplo, pero al pulsar el botón de Validar no ha pasado nada, pasados unos segundos.

En este caso, la mejor recomendación es aplicar el principio del in dubbio pro reo. Si aparentemente no ha pasado nada, debemos entender que realmente no ha pasado nada, y que la transferencia no se ha realizado. Todas las aplicaciones de calidad actualmente incorporan mecanismos de seguridad por el que nunca se da por concluida una operación hasta que todos los actores implicados han manifestado explícitamente su conformidad y han sido correctamente informados de su conclusión.

Cuando hago clic y nada ha pasado en unos
segundos, casi seguro que ya no pasará.
Mejor no acabar así.
(Fuente: antinformaticos)

Y lo siguiente, antes de concluir que la aplicación no funciona, conviene probarla con un Navegador diferente. Sí, nadie dijo que fuera a ser fácil. Cuando hago clic y no pasa nada, es muy probable que esté haciendo algo de una forma diferente a como lo espera quien diseñó la aplicación. Y como el Navegador es parte de lo que el usuario aporta a la aplicación, pues eso.  Conviene tener disponibles en nuestro PC al menos los navegadores más extendidos. Seguro que tendremos uno que es nuestro favorito y el que utilizamos habitualmente, pero conviene tener también los demás, para verificar la situación cuando se producen este tipo de casos. Por otra parte, si acudimos al Servicio de Atención al Cliente (del que ya hablaré in extensum en otra ocasión) alegando que la aplicación no funciona, es harto probable que la primera respuesta que obtengamos sea que la probemos con otro Navegador. Y lo curioso del caso es que, en la mayoría de ocasiones, con eso resolvemos el problema, por lo que más nos vale intentarlo de inicio, y no perder más tiempo.

Y, para ilustrarlo, tres ejemplos que he vivido en las últimas semanas. Es posible realizar apuestas online a las Loterías del Estado (Bono Loto, Primitiva, Euromillones,...) a través de la web oficial del Servicio. Se visualiza una parrilla (parecida al boleto físico de apuesta) donde podemos escoger las diversas opciones. Utilizando Google Chrome como navegador, a veces esta parrilla no se visualiza correctamente, aunque es posible realizar la apuesta igualmente si se elige la opción de Apuesta Automática; sólo es un problema de visualización. Utilizando Internet Explorer siempre funciona bien.

Intentando cargar unas fotos en un álbum online en la web de Viajeros, utilizando Google Chrome (que es mi favorito), no pasaba nada al pulsar el botón de Subir Fotos. Reporté el problema (que creo que ya está corregido) al Servicio Técnico, y me recomendaron probarlo con otro navegador. La prueba con Internet Explorer fue totalmente satisfactoria.

Intentando realizar, esta misma mañana, una transferencia en la web de ING Direct, me encontré con que no pasaba nada al pulsar el botón de Continuar, tras proporcionar todos los datos. Me desconecté y repetí la operación utilizando Internet Explorer, sin ningún problema.

Ante estas experiencias, algún lector suspicaz seguro que me preguntará por qué no uso como favorito el Internet Explorer. La respuesta es muy simple: porque es desesperantemente lento.

Ante un entorno tan terriblemente complejo, hay que tener cintura.

JMBA