La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada "Cuando la culpa es del usuario", en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra...todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad...si se electrocuta y muere...quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

• El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro...pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y....vamos, que está claro que sabemos pedir...pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
• El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos "XXX" como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
• El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery...o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

• Se trata de una aplicación web.
• En uno de los cambios de especificación, se añade soporte para iPad.
• La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
• Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
• Resultado: enfado del usuario y rediseño de la aplicación.
• ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

• El usuario no tiene culpa alguna de los errores que se producen.
• Es nuestra responsabilidad poner "paredes" y "puertas y ventanas" a la aplicación para permitir el acceso o no a las funcionalidades.
• Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
• Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
• Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
• Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días...añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).