La programación es un arte, no solo una ciencia
Llevo casi 30 años creando programas informáticos. Concretamente desde 1983. Y todavía me sorprende lo malos, lo rematadamente torpes, que son algunos programadores. Muchos, más de lo razonable. Durante muchos años, cuando hacía mis primeros programas en Basic en un ordenador de 64KB y luego en los primeros PCs que tenían 640MB de RAM en los mejores casos, las limitaciones del hardware justificaban, solo en parte, que algunos programas fueran un tanto burdos. Los recursos eran limitados y la prioridad era que el programa hiciera lo que «tenía» que hacer: por ejemplo, un listado de facturas pendientes de pago. La estética final ni se consideraba. La «usabilidad» no era ni siquiera un concepto a tener en cuenta. Al menos por la mayoría de los programadores.
Tengo una imagen grabada en la memoria, fruto de mis frecuentes viajes en tren, de la pantalla de venta de billetes de RENFE. ¡Era horrorosa! Por supuesto en fósforo verde. Eso es lo de menos. Lo que me llamaba más la atención, desde mi punto de vista ya entonces de programador, era la absoluta falta de interés del programador en organizar los campos en la pantalla. El número de tren, la hora de salida, el número de viajeros, la clase… los campos a introducir y los textos descriptivos se sucedían en la pantalla como una única línea de texto que saltaba al llegar al final de la pantalla y continuaba en la siguiente línea sin «maquetación» alguna. Nada estaba alineado con nada. No se agrupaban campos relacionados ni se resaltaban los más importantes, por ejemplo el precio o el número de billetes comprado.
Pero, para hacerlo más incómodo aún, muchos de los campos estaban codificados. Si ibas en litera, el campo clase era una Y (por ejemplo), mientras que el coche cama era una «X». Y la forma de pago una «C» o una «H». Lógicamente este lenguaje totalmente artificial obligaba a los vendedores de RENFE a consultar con frecuencia unas notas impresas en papeles desgastados y sucios llenos de sus propias anotaciones en bolígrafo. A veces las colas eran interminables. Sobre todo si había un empleado poco experimentado en el sistema.
Esa imagen, que se mantuvo durante años, era mi «anti-ejemplo». Ese programa reunía todos los defectos que quería evitar al hacer mis propios productos. Cuando empecé en 1987 a programar en dBase, con los mismos recursos gráficos que tenían los programadores de RENFE, y muchos menos recursos económicos, tenía muy claro que mis programas tenían que ser diferentes. Los campos se alinean y se agrupan: datos personales en un orden preciso, todos dentro de un rectángulo pintado con una linea sencilla. Los datos de facturación colocados aparte. Las columnas de datos perfectamente alineadas en vertical. Los datos importantes en negrita o con un fondo diferente. En cuanto tuve ocasión, empecé a usar colores (16, no había más). ¡Era realmente llamativo. Un programa de gestión con colores! Pero todo el mundo admitía que ver las facturas pendientes de pago en rojo (por ejemplo) resultaba más eficiente en el trabajo diario.
Que en 1987 el interfaz del programa de RENFE fuese tan malo ya hablaba mal de sus programadores. Pero que hoy, en pleno siglo XXI, con los recursos disponibles se sigan haciendo programas malos, pero malos… eso no tiene excusa.
Por ejemplo, el «nuevo» programa para introducir los CV de los profesores de las Universidades andaluzas, el SICA2. Es malísimo. Incómodo, poco intuitivo, farragoso… además se cuelga con frecuencia, para desesperación de los profesores y catedráticos que tienen cosas mejores que hacer que luchar a brazo partido con la horrorosa creación de unos programadores ineptos. No dejo de oir comentarios negativos, en Twitter por ejemplo.
Solo un ejemplo: al elegir el idioma de una publicación realizada por el profesor, ¡aparece una lista enorme con los idiomas de casi todo el Mundo! En orden alfabético. ¡El primero es el Africaner! ¿Es posible mayor estupidez? ¡Está el Guajiri!… Y el español, que debería estar el primero, por supuesto, aparece en la E, como uno más. ¿Saben estos inútiles programadores cuánto tiempo hacen perder a miles de profesores y catedráticos de Universidad eligiendo el idioma por cada una de sus decenas de publicaciones? ¿Saben el cabreo que produce? Cuando el 99% de las veces se elige el español y el 99,99% serán los 4 ó 5 más comunes. ¿Qué trabajo les habría costado haber puesto el español el primero y el inglés, francés, italiano y alemán a continuación?
Lo que consiguen es justamente lo contrario que Apple: destrozar la «experiencia de usuario», el gran secreto que hace que Apple haya vendido 65 millones de dispositivos con su sistema operativo iOS en el último trimestre de 2011. ¡Hay que mimar al usuario! Hay que ayudarle en su trabajo, mejorar su productividad ofreciéndoles las opciones más frecuentes en primer lugar, rellenando por él los campos con los datos más probables en función de los que va introduciendo, poniéndole «a mano» las respuestas mas plausibles. Hay que adaptar el software al usuario, y no al revés. Hay que perder unas horas de tiempo de programación (en realidad invertir, no perder) para ahorrar un minuto de uso a 20.000 usuarios 10 veces al día. Hay que hacer programas agradables, cómodos y ágiles.
Y todo esto tiene mucho que ver con los programas de gestión documental. No como con cualquier otro, sino con mucho mayor motivo.
La gestión documental en una empresa debe ser una opción de «o todo o nada». Si se instala un software y se digitalizan los archivos todos los miembros de la empresa lo tienen que usar. Desde el becario que acaba de entrar hasta el gerente. Eso quiere decir que habrá usuarios torpes, jóvenes y viejos, de perfil técnico y abogados. Por tanto es importantísimo que sea fácil de usar. Y ágil, que no lleve más tiempo del imprescindible.
Si no es así, fracasará. Porque un programa de gestión documental debe mejorar la productividad de la empresa. Si se convierte en una carga, si aumenta el tiempo necesario para realizar las operaciones que pretente agilizar, deja de tener sentido.
Ya he comentado ésto en varias ocasiones, pero cuando veo hoy mismo programas como el SICA2 o que el Ministerio de Justicia español se ha gastado 400 millones de Euros en la modernización de la Justicia y es un fracaso porque el sistema informático no funciona… cuando leo estas noticias me doy cuenta de que algunos programadores aún no se han enteredo de que una cosa es hacer las cosas y otras es hacerlas BIEN. Que un programa puede cubrir las funcionalidades previstas, ser correcto «técnicamente» y ser un desastre en la práctica. Que un programa no solo TIENE que hacer ciertas cosas, también DEBE tener ciertas cualidades.
La facilidad de uso es una de ellas. Es la que discuto cada día con mis programadores: ponte la «gorra» de usuario y dime si te gusta cómo ha quedado la nueva versión. Si no te gusta, mejórala.
Gestión Documental Para Gente (Casi) Normal 
También se podría culpar a los project manager, o a las prisas de la administración (en el caso del SICA2) por sacar un software que no está suficientemente probado, con una evaluación seria. Algo que en los 80 ni existía. ¿Qué prisa había por cambiar el SICA a otra versión? ¿Acaso temían que viniera un nuevo gobierno y les arrebataran «su tesoro»?
Quizás antes al programador no se le exigía, era un arte, y como tal no se podía presionar al artista más de la cuenta. En aquellos momentos era magia, ahora cualquiera sabe usar el dreamweaver y se piensa que estas cosas se hacen en 2 minutos y ya se irán corrigiendo «los fallillos» que aparezcan, ¡je!. Ahora las cosas distan mucho de ser así, en ese sentido hemos perdido capacidades.
Buen post, gracias!
Cuando paseas por una calle del centro de muchas ciudades ves de repente un edificio horrible, fuera de lugar, tremendamente feo. Pasa en todas las ciudades.
¿A quién culpamos inmediatamente? Al arquitecto. Quizás el promotor es más culpable, por contratar a un arquitecto «barato» o un proyecto barato. Y el Ayuntamiento también puede hacer algo.
Seguro que se dan todas las combinaciones posibles, igual que con los programas.
¡Pero poner una lista de idiomas en un software para profesores andaluces y no empezar con el español seguro, seguro que es un fallo del programador! Aunque si hay un jefe de proyecto, que debería, y no se ha dado cuenta, también le daría un buen tirón de orejas.
Hay problemas que se resuelven con buenas artes, no necesariamente gastando dinero. Yo, personalmente, en los programas que hacemos en nuestra empresa tengo como norma evitar los desplegables, por ejemplo. Son muy fáciles de usar y sirven para muchas cosas, pero son muy lentos para los usuarios que introducen los datos. ¡Y los usuarios deben ser siempre la prioridad para un programador!
Gracias por tu comentario. Lo comparto en su mayor parte.
Muy bueno Fernando. Por supuesto que la programación es un arte, quizá mucho más que otras actividades que se consideran arte. Es un arte no reconocido socialmente en la actualidad pero que lo será en el futuro. No se reconoce como arte ni siquiera a nivel institucional, ¿alguien ha caído en la cuenta? Ni siquiera la bien conocida SGAE, apoyada y financiada con dinero institucional ha pretendido defender los derechos de autor del software. Siempre han considerado artistas sobre todo a los cantantes y actores aunque el tiempo ha demostrado que ellos eran unos artistas del robo.
Habría un montón de ejemplos de mala programación con inversiones millonarias, programas no sólo difíciles de usar sino que también fallan. Por ejemplo cuando voy a comprar un billete para el AVE en la web de Renfe, siempre me pregunto por qué no es tan fácil como EasyJet o Rumbo.
Existen empresas muy grandes que hacen grandes chapuzas, no diré nombres pero se me ocurren algunas ubicadas en el parque tecnológico de mi ciudad en Málaga. Una de ellas estuvo haciendo la web de Iberia durante dos años sin lograr que funcionara, un desastre. Eso si, tenían al menos a 40 becarios escribiendo código para el proyecto, a mi modo de ver, con dos personas cualificadas hubiese bastado, esos eran los artistas que faltaban entre tanto decorado y parafernalia.
Un programa no sólo debe funcionar perfectamente también debe de facilitar el trabajo. Yo he dirigido varios proyectos de programación en los últimos años y con el tiempo he llegado a una conclusión radical: Si no es usable, no lo hagas. De nada sirve un programa con un montón de características, si el usuario no las comprende y por ende no las va a utilizar nunca.
Un problema en la programación es que el programador está más preocupado por demostrar lo que sabe hacer que por poner las cosas fáciles al usuario.
El programador asume como un reto personal resolver una dificultad técnica y ofrecer una solución. Puede hacer cosas de tremenda dificultad. La realidad es que no servirán de nada si el usuario no lo comprende o no se muestra en la aplicación de forma intuitiva.
En otro extremo, también tenemos las aplicaciones que yo denomino de tipo Hollywood. Son cómo esas películas llenas de efectos especiales y carentes de contenidos. Me refiero a esas aplicaciones cargadas de elementos decorativos, unas ventanas muy bonitas, efectos de transparencia, unos iconos preciosos.
La primera vez que se ven impresionan muchísimo, esto se vende muy bien, otra cosa es el uso diario, que es cuando te das cuenta de que todo esto sobra y te molesta. Aquí impera la estética sobre la funcionalidad. Esto puede ser aplicable por ejemplo a Windows Vista con respecto a su antecesor Windows XP o la nueva web del BBVA, me hace perder horas con sus ventanitas.
Una buena aplicación debe mantener el equilibrio entre funcionalidad, usabilidad y estética. Esto no es fácil de conseguir, porque también es cierto que en la actualidad el usuario no está dispuesto a hacer un pequeño esfuerzo de comprensión de la aplicación, ya nadie quiere leer manuales o incluso pensar un poco. Si encima la aplicación hace perder el tiempo y está mal hecha el cabreo está garantizado. Desde luego, el usuario que se encuentra el Africaner como primera opción de idioma no es el que tiene que hacer el esfuerzo en este caso, algunos programadores no piensan en absoluto.
Hola Fernando, muy de acuerdo contigo, la programación entre en categoría de arte muchas veces y siempre he mantenido que un buen programador lo es en COBOL, en C++ y en Java, no es dependiente tanto del lenguaje utilizado. Por otra parte doy la razón también a arturogf, hoy en día parece que todo tiene que salir sin probar y sin casi pensar, en el caso de las provincias, si el programador no tiene tiempo ni de caer en la facilidad de poner el Español en primer lugar porque tiene que terminar todo «hoy noooo,… mañana!», copia y pega la típica lista de provincias que encuentra y pasa de todo. Por último lo que dice Francisco Javier es totalmente cierto sobre las aplicaciones Hollywood, jejeje, he visto yo ya unas cuantas de estas.
Un buen artículo Fernando.
Gracias por el comentario. Está claro que los que nos dedicamos a ésto lo tenemos claro. Otra cosa son nuestros clientes 😉