Gestión Documental Para Gente (Casi) Normal

O cómo las matemáticas te pueden ayudar a hacer buenos programas.

Es una pregunta que casi todos los niños hacen alguna vez en su vida (algunos la siguen haciendo de adultos). ¿Para qué me sirve aprender matemáticas? ¿Para qué sirven las funciones, las derivadas, las raices cuadradas…? Y no digamos las ecuaciones diferenciales o las series de Fourier.

La respuesta es obvia: las matemáticas son una herramienta con la que resolverás problemas que encontrarás en el futuro. Claro que esa explicación funciona bien para las operaciones básicas, pero cuando hablamos de derivadas resulta más difícil encontrar un ejemplo de «la vida real». Sin embargo, incluso en el diseño del software podemos encontrar aplicaciones prácticas a las series convergentes, a sistemas de control retroalimentados. ¿Seguro?

En realidad, algo tan cotidiano como darse una ducha lleva detrás una interesante carga matemátia. Lo normal cuando te duchas es que el agua empiece saliendo fría. Introduces tu «sensor» (la mano o un pie) debajo del chorro de agua y esperas a que se caliente. Lo siguiente, al menos en mi ducha, es que salga demasiado caliente y tu «sistema de control» (el cerebro) te dice que cierres un poco el grifo del agua caliente y esperes (esta es la clave) a ver cuánto baja la temperatura. Una persona nerviosa podría no encontrar nunca la temperatura justa. Al salir caliente cierra demasiado bruscamente el agua caliente y se pasa. Al encontrarla ahora demasiado fría vuelve a abrir demasiado la caliente y vuelve a quemarse. Y así se pasa el rato, del frío al calor.

Hay un aspecto clave en todo sistema de control (incluida la ducha): la respuesta tiene que ser más lenta que el tiempo de reacción del sistema. Un sistema con esta «cualidad» es estable, tiende al equilibrio (ducha templada) mientras que la reacción «nerviosa», más rápida que el propio sistema, es inestable.

Un ejemplo más tecnológico es el piloto automático de un avión. Cuando el avión vuela en equilibrio, en linea recta, y sufre una turbulencia (una ráfaga de viento lateral, por ejemplo), el avión se inclina y el piloto automático reacciona moviendo los alerones para compensar la ráfaga y volver a la posición de equilibro. Después de varias oscilaciones, en teoría cada una más pequeña que la anterior, el avión vuelve a su posición inicial. Si el pilóto automático no estuviera bien diseñado, si fuera un tipo nervioso, las correcciones provocarían oscilaciones cada vez más grandes y el avión se estrellaría. Si alguna vez has manejado un helicóptero de radio control sabes perfectamente a qué me refiero.

¿Y todo esto que tiene que ver con el software? Bastante. Sobre todo con los basados en Internet (ya sabes, los del Cloud Computing). Y más aún si incluye la consulta de documentos «pesados».

Los usuarios de programas informáticos necesitan saber cuándo han pulsado una opción: un botón, una marca de verificación, un vínculo… Incluso cuando pusamos una tecla. Es lo que en el principio de la informática se llamaba «ECO». Cuando este «eco» falta o simplemente se retrasa… nos ponemos nerviosos (como el de la ducha). Ya no sabemos si hemos pulsado esa tecla, si hemos hecho clic sobre el botón «Enviar»… y repetimos la acción. Y puede pasar cualquier cosa: que me salte un formulario sin rellenar, que las palabras que escribo tengan teclas repetidas, que envíe tres veces la misma respuesta (eso me ocurrió a mí hace solo un par de días).

Es muy importante «decirle» al usuario que YA ha pulsado ese botón. Tiene que recibir alguna confirmación. Y el tiempo que trascurre desde que pulsa el botón hasta que recibe la confirmación debe ser MUY breve. Si no, volverá a pulsarlo.

¿No es grave? Hace unos meses la página de la Universidad de Granada se colapsó porque los alumnos pulsaban 3 ó 4 veces el botón de envío de solicitudes y en cada ocasión se creaba una nueva conexión. El sistema se desbordó porque estaba dimensionado para un número de alumnos muy inferior al que estaba atendiendo, aunque fueran los mismos repetidos.

A pequeña escala, estos pequeños retrasos, y los errores que provocan, pueden llegar a ser muy molestos si se producen continuamente.

Así que, cuando diseñes un programa, asegúrate de que sea un «sistema estable», es decir, que el usuario reciba un «eco» siempre que realice una acción.

Y si eres un usuario, paciencia. Los ordenadores son muy rápidos pero cuando se conectan a un servidor en Internet no siempre van a la velocidad que tú quisieras.