La Informática: eso que usamos, sufrimos y desconocemos.

Perdidos

 Un buen día de esos días en los que iba yo de ordenador en ordenador, USB en mano, me dije que no podía seguir así y me fui a la tienda más cercana a comprarme una USB de esas que llevan un interruptor que impide la escritura en el dispositivo. Lo malo de las USBs cuando las llevas de ordenador (ajeno) en ordenador (ajeno) es que tú llegas al primer ordenador con ella limpia (sin virus), pero cuando llegas al segundo ya no estás seguro si no se infectó en el primero y ahora estás tú propagando el virus. La única protección realmente fiable para estas memorias es ese interruptor. Mi primera USB lo llevaba, pero, por lo visto, esto no es algo muy apreciado por el gran público, por lo que han caído en desuso. Así que me tocó recorrerme todas las tiendas del barrio en busca de una de ellas. En la mayoría de las tiendas me dieron la misma idéntica respuesta:

- Estas, señor, ya no se fabrican.

Esto no es cierto, es decir, es mentira. Algunos fabricantes siguen fabricando y comercializando algunos de sus modelos de este tipo, con interruptores de protección contra escritura. Solo se me ocurren dos razones para que un vendedor me diga algo que es falso: falta de competencia técnica o falta de honestidad. Hay una gran diferencia entre que el vendedor te diga "no tenemos" o que te diga "no existen". Hay una gran diferencia entre que el vendedor piense que él está ahí para venderte lo que tú necesitas o que el vendedor piense que tú estás ahí para comprar lo que él vende.


Esto fue una experiencia. Solo una experiencia. Otra más, de tantas.

 

¿Qué es lo que ocurre?

Cuando entramos en la tienda de informática, nos recibe un vendedor. Nosotros lo vemos, más o menos, así:

Vendedor Imagen © Fallenangel Stock Free Images

 



 Sin embargo, lo que el vendedor ve puede que sea más bien algo así:

Cliente Imagen © Idless | Stock Free Images

  Efectivamente, querido lector o lectora, para el vendedor seguramente, más que una fuente de ingresos a cuidar con mimo y profesionalidad, seamos simples vacas lecheras a las que ordeñar cuanto sea posible, como sea posible y lo más rápidamente posible.

 

 - ¡Pero, por Dios! ¿Cómo puedes decir eso? ¡Qué negativo! ¡Qué exagerado! Tú no tienes amigos, ¿verdad?

 

 ¿Estoy siendo muy negativo? ¿Exagerado? ¿Cómo se explica, entonces, que alguno de los que muchos califican como uno de los peores productos tecnológicos de la historia reciente haya sido a su vez también uno de los más vendidos? (¡Y Windows Vista no es precisamente el único producto infame que ha sido un éxito de ventas!)


 

Hagamos un breve ejercicio de empatía. Imaginemos que somos ese vendedor. Nos entra un cliente por la puerta. Vamos a venderle un sistema operativo. Veamos... comparemos un par de posibilidades...

  •  [Sistema operativo Nº 1] Este sistema operativo aprovechará bien los recursos del equipo, es seguro, estable, y viene acompañado de todos los programas que un usuario "típico" puede necesitar. La licencia es gratuita.
  • [Sistema operativo Nº 2] Este otro sistema operativo es ineficiente en el aprovechamiento de los recursos del equipo, y se degrada mucho más rápidamente que el anterior; por tanto, el cliente necesitará comprar un nuevo equipo mucho antes que con el otro. Dinero para el vendedor. La posibilidad de que un virus lo infecte es mucho mayor, así que el cliente probablemente tendrá que traer el ordenador a arreglarlo alguna vez. Más dinero para el vendedor. Viene sin apenas programas, por lo que el cliente tal vez compre alguno. Más dinero. Y, por supuesto, la licencia no es gratis, así que el vendedor ganará por el mero hecho de venderlo. Dinero, dinero, dinero.

 Ahora... pensemos... ¿cuál será el sistema operativo con el que el vendedor tratará de cubir las necesidades del comprador, como dicen ellos, o de ordeñar a la vaca, como (exagerada y negativamente) digo yo?

Dinero, dinero.  Imagen © Simonkr | Stock Free Images

 


Si hemos respondido que "el segundo", ¡enhorabuena!, lo hemos entendido. De hecho, tanto es así que cuando entramos a la tienda solo encontraremos este, y no el primero. El primero del que te estoy hablando se llama GNU/Linux y puedes incluso descargarlo gratuitamente de Internet, en una multitud de variedades adaptadas a diferentes gustos y necesidades. En las tiendas no suelen ofrecértelo. En la mayoría de las tiendas, es como si no existiera. Si entras en una tienda y no te ofrecen equipos con este sistema, ¡huye! Sal de ahí inmediatamente, porque en esa tienda eres una vaca. Y, sí, repito e insisto: eso ocurre actualmente en casi todas.

¿Porqué ocurre esto? Esto ocurre porque la inmensa mayoría de los clientes no tienen ni puta idea de informática. Muchos de los clientes llaman "saber informática" a mover el ratón por la pantalla, hacer clics en los menús y cuatro chorradas más; siendo que esto podría hacerlo un chimpancé con algo de entrenamiento o cualquier crío que sepa leer sin apenas necesidad de ningún adiestramiento. El problema de esto es que cuando vamos a la tienda(ya sea que vamos a comprar un ordenador para casa, un programa para la empresa, o lo que sea) estamos en situación de indefensión. El problema de esto es que salimos de la tienda con lo que salimos de la tienda. El problema de esto es que los problemas con eso no han hecho más que empezar en ese momento.

 La ignoracia es cara. Es muy cara. La ignoracia la pagamos al comprar, cuando compramos productos caros por no saber que existen otros más baratos o cuando compramos productos creyendo equivocadamente que son los mejores y pagando como si lo fueran. Y la seguimos pagando después, cuando utilizamos lo que hemos comprado sin saber usarlo bien (probablemente sin siquiera ser conscientes de ello).

 

Miren, oigan, yo no tengo formación artística, así que cuando entro en un museo de arte a lo más que llego es a decir qué me parece bonito y qué me parece feo, pero no estoy ni remotamente capacitado para valorar lo que estoy viendo. En no pocas ocasiones me conformaría con ser capaz de distinguir lo que es arte abstracto de lo que es vandalismo. Me gustaría que alguien me explicara cuatro cosas básicas para no ir... tan... perdido. No quiero un curso de pintura ni convertirme en pintor: no tengo ni talento, ni tiempo, ni ganas. No quiero convertirme en marchante de arte: sospecho que adquirir las capacidades necesarias para distinguir una obra original de una buena falsificación debe ser algo bastante complejo. Pero sí me gustaría entender algo de pintura. Esta es la idea.

A los que ya no somos tan jóvenes como quisiéramos, un buen día nos apareció el ordenador en nuestro puesto de trabajo y en nuestras vidas, y quien más o quien menos, con más o menos ganas, nos hemos ido buscando la vida para convivir con ellos. Pero cuando pregunto a los más jóvenes de mi familia por su formación en informática, me escandalizo. Me escandalizo por lo que se les enseña, por cómo se les enseña y, aún más, mucho más, por lo que no se les enseña. Y se les llama nativos digitales y leo en textos y prensa cómo personas que no tienen ni puta idea de informática hablan de ellos como si fueran innatos expertos; como si por el mero hecho de haber nacido entre piedras ya fueses experto en "geología".

- ¡Fíjate, fíjate, Julián! ¿Has visto mi chico, lo lejos que tira la piedra?

- Se nota que estos chavales han nacido entre piedras, ¿eh? No como nosotros, que nos criamos en el mar.

- Sí, se les da muy bien la petrología. Claro, no le tienen ningún miedo...

 


Y estos son los afortunados que se supone que cuentan con alguna formación seria en informática. La mayor parte de los actuales usuarios de informática no han tenido nunca ni eso. Usuarios que tienen que comprarse sus ordenadores, escoger programas, adaptar sus negocios a las novedades tecnológicas... Usuarios que necesitan entender algo de informática pero que están perdidos.

 

Este "libro" pretende enseñar algo de informática a quienes no tienen ni puta idea de informática. No vamos a contarte que para abrir un archivo tienes que ir al menú Archivo y seleccionar la opción Abrir. Aquí te contaremos los conceptos básicos e importantes que todo usuario o cliente debería de conocer: esos conceptos que te ayudarán a saber elegir, a saber comprar y a saber trabajar. Esperamos que te guste y, sobre todo, que te resulte útil.


Mi primera vez con una computadora

Yo soy físico. Mi primer contacto con las computadoras fue durante la carrera, en cuarto curso. En una asignatura teníamos que diseñar un sistema óptico y estudiar sus aberraciones. Esto consistía en escoger la geometría de las lentes, sus índices de refracción, e ir calculando la trayectoria de los rayos de luz que atraviesan el sistema. Sí, he dicho calculando: es el típico problema para resolver por ordenador.

Por aquel entonces no había aulas de informática: eran todo aulas, a secas. El profesor entraba en clase y te escribía en la pizarra, con tiza, unos comandos que tú te apuntabas en el cuaderno, con boli, para luego escribirlos en el ordenador.

Recuerdo el primer día que acudí al Centro de Cálculo a poner en práctica mis recién adquiridos conocimientos como si fuese ayer. Bajé a una hora en la que todo el mundo estaba comiendo, menos yo, por lo visto. Allí había una sala con terminales para que los usuarios hiciésemos nuestras prácticas. Los terminales eran una especie de baúl con pantalla de fósforo verde y un teclado con aspecto de haber sido diseñado por los mismísimos enanos de las minas de Moria. Y allí estaba yo, solo, rodeado de terminales... apagados.

Me acerqué al primero de ellos y lo estudié como los monos de 2001: Odisea del espacio hacían con el monolito. No descubrí ni rastro de botón o interruptor alguno para encender aquel cacharro. Entonces empecé a toquitear el teclado, con aquella precaución aprendida de las aves rapaces que nos enseñaba de pequeños el amigo Félix Rodríguez de la Fuente en sus documentales, intentando insuflar algo de vida en aquel objeto inerte. Sin éxito. Repetí el ritual en algún otro aparato, con el mismo resultado.

Ante la soledad y el fracaso, decidí meterme el rabo entre las piernas y batirme en retirada, en busca de refuerzos.

Ale, ya puedes decirlo: ¡Qué tonto, el César, que no supo ni encender el terminal!

Pues no. ¡EEEEEEERROR!

Este es uno de los errores más extendidos entre la gente que se ha sentado, se sienta o se va a sentar frente a un ordenador, y que, hoy en día, ya somos casi todos; y también entre la que no. Me refiero a pensar que si no sabes hacer algo, por sencillo que sea, es porque eres tonto.

¿Estamos de acuerdo en que el estado natural del ser humano es la ignorancia? Lo normal es ser ignorante. Ignoramos la mayor parte de las cosas. Cuando nacemos, nacemos ignorándolo todo: no sabemos absolutamente nada. Después vamos aprendiendo algunas cosas, y finalmente terminamos adquiriendo algunas ideas ciertamente ridículas. Decimos, por ejemplo, cosas del tipo de que "el alemán es más difícil que el español". Vamos a ver, vamos a ver... ¿El alemán es más difícil o nos parece más difícil? Porque si el alemán fuese difícil y el español fuese fácil, probablemente, lo que ocurriría sería que los tontos hablaríamos español y el alemán estaría reservado para los listos. Pero no, lo que en realidad ocurre es que el español lo hablan los nacidos en España, mientras que el alemán lo hablan los nacidos en Alemania.

 

Aún recuerdo aquella tarde en casa de mi amigo Juan, con su recién comprado Olivetti. Eran los tiempos del MS-DOS. En su pantalla, completamente negra, un prompt burlón nos invitaba a introducir unos comandos que desconocíamos, para que aquello hiciese algo. ¿Y ahora qué? - nos preguntábamos mirándonos el uno al otro. Y no te quedaba más remedio que agarrar el manual y ponerte a estudiar los comandos para hacer funcionar aquel cacharro. Pero no nos sentíamos tontos por no saber, ni nos resultaba extraño. Y sabíamos cual era el remedio: aprender. ¡Y nos poníamos a ello! Era lo natural, y nos parecía lo natural.

Después empezaron a popularizarse los interfaces gráficos de usuario, que se manejaban con el ratón. Entonces ya no te tenías que ir a estudiar y volver cuando hubieses aprendido: podías comenzar a dar vueltecitas por la pantalla con el puntero del ratón, deplegar menús aquí o allá, e ir pinchando cosas hasta conseguir hacer algo. Nos pusieron muy fácil usar el ordenador y, con ello, usarlo mal. Nos pusieron muy fácil que nos olvidásemos de que había que aprender informática. Nos vendieron la idea de que bastaba con ponernos delante del ordenador y su halo tecnológico nos envolvería mágicamente convirtiéndonos en expertos usuarios de computadoras. Y nosotros nos lo creímos.

Como consecuencia de esto, mientras que el hardware del ordenador iba siendo mejor cada día, cada día los usuarios iban siendo peores.

Cuando el usuario se encuentra ante algo nuevo, más o menos extraño, con lo que no está familiarizado, probablemente lo calificará de "difícil" y le producirá rechazo. Es posible, incluso, que se sienta mal por ello o que le hagan sentirse mal por ello. Como consecuencia, es posible que vaya a buscar un hombro en el que llorar sus penas o unas manos amigas que le acaricien el lomo, en lugar de acudir a lo que realmente necesita: un libro (o similar fuente de formación).

Un Sistema Informático tiene tres componentes: hardware, software y personas. Las personas son el elemento frecuentemente olvidado (obviado) de un sistema informático. Son personas quienes crean el sistema, son personas quienes lo mantienen, y son personas quienes lo manejan: esas a las que llamamos usuarios. La calidad del sistema estará siempre limitada por la menor de los elementos que lo componen: nada hará mejor un mal hardware, no hay hardware lo suficientemente bueno que un mal software no pueda arruinar, y no hay sistema que un bendito usuario no sea capaz de destrozar.

Tengo personal predilección por fijarme en este componente de los sistemas informáticos, el más olvidado de ellos. Desde hace ya bastante tiempo, en ámbitos médicos se viene trabajando en concienciar a los profesionales de que trabajan con enfermos y no (únicamente) con enfermedades. De estas cosas los informáticos todavía no nos hemos enterado y somos los primeros en olvidarnos de las personas, ocupándonos únicamente del hardware y del software. ¡Error!

El usuario es una parte crítica de nuestro sistema informático. Si queremos que nuestro sistema informático no se degrade, debemos recordar dos cosas importantísimas: que los usuarios no somos tontos, y que los usuarios necesitamos formación.

 

La madre del cordero

Estaba en mi cuarto curso de carrera cuando cursé una asignatura llamada Métodos y Sistemas de Cálculo Numérico. ¿He dicho Cálculo? Sí, he vuelto a nombrar el término que hace aparecer a las computadoras. Fue una suerte hacer aquella asignatura, porque en aquella asignatura aprendí a programar, y la programación es la madre del cordero en esto de la informática.

En aquella asignatura, para hacer las prácticas, aprendíamos los fundamentos de la programación en un lenguaje llamado FORTRAN. Un lenguaje tan bien elegido, por cierto, que no lo he vuelto a usar en toda mi vida. En cualquier caso, una elección mucho más fácil de justificar que algunas elecciones que se hacen actualmente en algunas universidades; lo cual no tiene ni la más mínima importancia, porque si en algo somos buenos los informáticos es en justificar nuestras elecciones, aun cuando nuestras elecciones sean una mierda. Pero, en fin, dejemos esto y volvamos a lo que íbamos...

Veamos los seis conceptos globales más básicos (y, por tanto, importantes) en esto de la programación:

¿Qué es programar? Programar es conseguir que el ordenador sepa hacer lo que alguien sabe hacer.

¿Qué es un programador? Es una persona que programa.

¿Qué es un lenguaje de programación? Un lenguaje de programación es un lenguaje inventado para que el programador le diga al ordenador cómo se hacen esas cosas.

¿Qué es el código fuente? Son las instrucciones que el programador escribe en el lenguaje de programación, es decir, en un formato legible para el programador.

¿Qué es compilar? El ordenador (el procesador) no es capaz de entender directamente el código fuente. El código fuente son letras, números y caracteres que un ser humano (el programador) puede entender. El ordenador procesa bits (eso que llaman "unos y ceros"). Compilar es pasar de ese lenguaje para humanos a lo que la computadora es capaz de procesar.

¿Qué es un programa? Es un conjunto de instrucciones escritas en un lenguaje de programación. Se le llama programa tanto cuando está en el formato que el humano puede entender (fuente) como cuando está en el formato adecuado para la computadora (binario).

Si todos estos conceptos son totalmente nuevos para ti, sería conveniente que los vieses en la práctica. Pilla a tu amigo el informático y dile que te enseñe a hacer un programilla (script). Para eso solo necesitas un editor de textos (vale hasta el bloc de notas) y el tiempo que tardes en escribir una línea de texto y guardar el archivo. Después dile que te enseñe a ver el código fuente de las páginas web, y que te explique un poquillo qué significa todo eso. Suficiente.

Repasemos, a ver si lo hemos entendido...

En el mundo físico (real) hay personas que saben hacer cosas. Después hay programadores, que son personas capaces de entender cómo se hacen esas cosas y de escribir los programas para que esas cosas puedan hacerse por ordenador. Esas cosas pueden ser: escribir una carta, calcular una nómina, enviar un correo, efectuar cálculos científicos... Los programas harán esas cosas, o le ayudarán al usuario a hacerlas. El usuario le dice al ordenador que ejecute un programa, lo que significa que el ordenador ejecutará las instrucciones que el programador programó en ese programa.

¿Hemos entendido que el código fuente es la base de toda la informática?

Si realmente hemos entendido que el código fuente es la piedra angular de toooooda la informática, y entendemos la importancia que la informática tiene en nuestro presente y tendrá en nuestro futuro, estaremos en disposición para valorar por nosotros mismos la importancia de tener y de poder leer y entender el código fuente; y estaremos en disposición para valorar por nosotros mismos una decisión como la de eliminar la programación del currículo de nuestros escolares, dando lugar a no sé cuántas hornadas de jóvenes que terminan su formación reglada sin ser capaces, ya no solo de programar, sino de leer una sola línea de código.

Si lo pensamos, tal vez lleguemos a la conclusión de que lo de justificar decisiones, aunque las decisiones sean una enorme cagada, no es exclusivo de los informáticos. Lo dejamos como ejercicio para el lector.

 

 

Las expectativas razonables

En 5º curso teníamos un par de asignaturas optativas, y podíamos elegir incluso asignaturas de otras carreras, así que yo me cogí una del plan de matemáticas, Computación II, en la que aprendí a programar en C. Daba aquella asignatura la gran profesora Pilar Lasala, autora de varios libros sobre la materia. En uno de ellos leí algo que me escandalizó: su explicación sobre el procedimiento con el que se creaban los programas.

El primer paso –explicaba–, es escribir el programa (el código fuente). Una vez escrito, se compila. A continuación, se ejecuta el programa y se buscan los fallos. Se corrigen los fallos (en el código fuente), se vuelve a compilar, se vuelve a ejecutar y se buscan más fallos. Se repite el proceso hasta que no podamos encontrar más fallos.

Me escandalicé al leer esto porque a mí esto me sonó a enoooorme chapuza, algo que me resultaba inadmisible que estuviese escrito en un libro. Yo era el típico idiota que se creía más listo que nadie, así que para mí era evidente que el proceso correcto era escribir bien el código fuente, perfecto de partida, sin errores: lo de andar buscando y corrigiendo fallos una y otra vez no era de recibo, oiga.

Han pasado unos 20 años desde entonces. He pasado casi tantos diciéndome a mí mismo “¡qué razón tenía aquella mujer!” y avergonzado de mi estúpida ingenuidad.

Resulta que escribir un programa sin errores es sencillo cuando el programa es trivial (tan trivial como aquellos programas que yo escribía cuando estaba aprendiendo a programar), pero cuando el programa crece en tamaño y complejidad, la cosa se complica muchísimo. ¡Muchísimo! Entender el porqué es muy fácil: ver los errores en un programa con pocas líneas de código es tan sencillo como encontrar una aguja en un pajar sin paja: la dificultad de encontrar la aguja en el pajar la pone la cantidad de paja. Conforme aumenta el número de líneas de código, aumenta la probabilidad de que al programador se le cuele un gazapo, y aumenta así mismo la dificultad para encontrarlo. El programador cuenta con herramientas automáticas que le ayudan a encontrar gazapos, del mismo modo que un usuario cuenta con un corrector ortográfico para encontrar sus faltas de ortografía. Pero del mismo modo que un corrector ortográfico no encontrará ciertas faltas de ortografía, las herramientas del programador no encontrarán ciertos errores sintácticos o lógicos en sus programas.

Aun cuando el programador fuese capaz de escribir un programa sin errores sintácticos ni lógicos, resulta que este programa haría lo que el programador pensó que debería hacer y como el programador pensó que debería hacerse, ¿lo recordamos? Para programar el programa, el programador piensa en todos los casos que se vayan a poder dar, en todas las posibilidades, en todas las circunstancias... Si el programa no es trivial, fácilmente podremos tener millones de casos posibles cuando el usuario ejecute el programa, la mayoría de las cuales estarán dentro de lo contemplado por el programador; pero algunas no lo estarán, dando lugar a errores o mal funcionamiento en tiempo de ejecución.

Por si todo esto fuera poco, hemos de tener también en cuenta que los programas no lo hacen todo por sí mismos, sino que confían en otros programas, programados por otros programadores, para hacer muchas de las tareas que deben hacerse. Por ejemplo, cuando un programador programa un programa de nóminas, el programador no programa cómo se dibujarán puntito a puntito los botones que aparecerán en las ventanas que aparecerán en el monitor, ni programará cómo se accede a la unidad de almacenamiento para recoger o dejar la información, ni otras muchas cosas: lo que el programador programará será fundamentalmente la lógica del cálculo de nóminas y una interfaz para el usuario, y para que todo esto funcione confiará en los programas de terceros.

Resumiendo, podemos decir que el apocalíptico (pero real) panorama que tenemos delante, cuando lo que tenemos delante es un sistema informático no trivial, es que: es casi imposible que el programador haya escrito lo que quería programar sin ningún error, que además es casi imposible que lo que el programador quería programar no tuviese errores (es decir, contemplase perfectamente todas las posibilidades posibles), y que además es casi imposible que el programa funcione sin errores (aun cuando el programador perfecto hubiese programado el programa perfecto) debido a que el programa necesitará de otros programas cuyo funcionamiento perfecto es casi imposible por las mismas razones. A poco que entendamos de probabilidad, nos haremos fácilmente a la idea de que crear un programa (no trivial) sin fallos podría calificarse de milagro.

El usuario medio, sin embargo, desconocedor de todas estas dificultades, lo que espera es que todo funcione bien siempre.

Conocí a un tipo llamado David, uno de esos con un gran talento. Era Director de Calidad en una empresa en la que trabajé. Él expresaría este hecho diciendo que “el usuario medio tiene unas expectativas de calidad poco razonables”.

Que las expectativas del usuario no sean razonables es perjudicial para el usuario y perjudicial para el informático, es decir, perjudicial para todos.

Supongamos, por poner un ejemplo, que somos un usuario de cierto programa. Si esperamos que el programa satisfaga todas nuestras necesidades, se comporte siempre como queremos, y nunca falle, probablemente más pronto que tarde la realidad se encargará de desengañarnos. Como consecuencia, nos sentiremos frustrados. Si no queremos padecer esta desagradable sensación, más vale que vayamos asumiendo que los fallos y las carencias van a estar siempre ahí: estas o aquellas, en este o en aquel programa. Cuanto antes asumamos que la informática es imperfecta, antes podremos ser felices (o no demasiado desgraciados) con ella.

Supongamos, por poner otro ejemplo, que somos un empresario que quiere encargar un desarrollo a medida (un programa específico para la empresa, una aplicación web...). Si no somos conscientes de todo lo anterior, pensamos que es todo muy fácil y esperamos que todo funcione a la primera, bien y siempre, cuando el informático nos pase un presupuesto nosotros pensaremos que intenta timarnos. Entonces, nosotros rebajaremos el precio; con lo cual el informático o bien rechazará el trabajo o bien nos hará una chapuza. No estar dispuestos (¡por creer que no lo vale!) a pagar el precio que vale un trabajo bien hecho, acabará pasándonos factura. Cuanto antes asumamos que el trabajo de programar es un trabajo difícil y laborioso, antes podremos valorar adecuadamente los presupuestos que nos presenten. (Por supuesto, la otra parte de hacer una buena compra es no pagar por una chapuza el precio de un trabajo bien hecho.)

Muchos informáticos son tipos muy listos que hacen muy bien su trabajo, por lo que hay muchas cosas que funcionan muy bien casi siempre. Por otra parte, los vendedores (profesionales o aficionados) siempre recomiendan sus productos como si fuesen perfectos, aun cuando estén muy lejos de serlo. En informática (como en cualquier otra cosa), perfecto no hay nada y todos dicen que lo suyo es lo mejor.

Tres consejos, a modo de resumen, para ser felices y para que no nos engañen: Tengamos expectativas realistas, no confiemos ciegamente en las valoraciones ajenas, y aprendamos a valorar las dificultades y el trabajo que lleva hacer bien las cosas.

 

 

Corregir los errores

Probablemente usted haya visto esas imágenes de Windows colgándose el mismísimo momento en el que Bill Gates lo presentaba al público. ¿Ocurre esto porque Bill tiene muy mala suerte? ¿Porque Windows es muy malo? No, esto ocurre porque es un software complejo, y el software complejo esconde errores que le hacen fallar (a veces en el peor de los momentos).

¿Cómo se hace para quitar los errores del software? Bueno, pues... lo primero es encontrarlos.


Como encontrar errores en un software demasiado complejo sería como buscar una aguja en un pajar, la búsqueda comienza a hacerse componente a componente, a medida que estos se van programando. El programa estará formado por muchos (¡muchos!) pequeños componentes. El programador (u otra persona) probará el componente como si de un pequeño programa se tratara. Una vez que le de el visto bueno, pasará a formar parte del programa junto con el resto.

Una vez aquí, el componente, que no fallaba de modo aislado, puede comenzar a fallar debido a su interacción con otros componentes. Puede que el programador A y el programador B no se hayan puesto perfectamente de acuerdo en un tipo de dato que el componente A y el componente B intercambian en cierta operación, y entonces puede que se produzca el fallo que no se producía con los componentes aislados. O bien puede ocurrir que en su día al programador A se le escapó un fallo: cierta operación del componente A no se comportaba exactamente como debía comportarse. El programador B desarrolló su componente según el comportamiento real (no el esperado) del componente A. Más tarde, el programador A corrigió su error: ahora el componente A se comporta como siempre debió comportarse, pero no es ese el comportamiento que espera ahora el componente B. Cuando alguien introduce el componente A corregido, el componente B puede empezar a fallar debido al comportamiento corregido del componente A.

Viendo que un programa no trivial puede fácilmente estar compuesto por cientos o miles de componentes, que cada componente puede realizar decenas o cientos de operaciones distintas, y que probar cada operación puede implicar decenas de pruebas, empezaremos a comprender que probarlo absolutamente todo necesitaría tal cantidad de pruebas que ningún fabricante podría asumir su coste.

Y... ¿Habríamos terminado con esto de probarlo todo? Pues no. Es posible que el componente que en nuestra máquina funciona perfectamente, no funcione o no funcione bien en otra máquina. La primera razón es porque en esa segunda máquina nuestro componente puede interaccionar con componentes distintos que los que había en nuestra máquina. Volvemos al caso anterior pero con este nuevo factor de complejidad. Otra razón puede ser que nuestro componente realice alguna operación que sea sensible a la arquitectura de la máquina, y que esta sea distinta a la de nuestra máquina. Otra razón puede ser que la capacidad de la máquina sea distinta a la de la nuestra: así puede que en una máquina con menos recursos aparezcan fácilmente fallos que con más recursos quizás nunca encontraríamos, por ejemplo. Otra razón puede ser que en esa segunda máquina se estén ejecutando procesos que no se ejecutaban en la mía. Otra razón puede ser que yo no lo probé teniéndolo en ejecución durante el tiempo suficiente. Otra razón puede ser... ¡Hay tantas!

Pero supongamos que mediante ingeniería genética hemos conseguido crear el infornejo: un cruce perfecto entre informático y conejo, con la capacidad reproductora de este último pero con la capacidad de trabajo a bajo coste y en condiciones precarias del primero. En poco tiempo, gracias a su gran capacidad de reproducción, tenemos miles o decenas de miles de infornejos trabajando en probar nuestro programa. Incluso supongamos que uno de ellos ha digievolucionado a infornejo-mesías (algo así como archimago nivel 53) y es capaz de multiplicar las pruebas a su antojo, con lo que podemos probar todo lo que hemos dicho que había que probar, y en cualquier circunstancia. ¿Habríamos terminado con esto de probarlo todo? Pues no.

En este momento tendríamos un programa que funcionaría perfectamente... según lo pensó el programador. Pero, ¿lo pensó bien el programador? Podría ser que el cliente pidió un programa para el cálculo de nóminas y lo que el programador le entregó fue un juego de marcianos; un juego de marcianos, eso sí, que funciona perfectamente. Lo que queda por probar todavía es que el programa hace lo que tiene que hacer y como lo tiene que hacer. No siendo tan exagerados como en el ejemplo anterior (aunque esa es la idea), podría ocurrir que el programa no resultase fácil de manejar, que no hiciese las cosas de un modo operativo, natural, eficiente...

Para terminar de probar todo esto, el programador recurre a la realización de las llamadas pruebas alfa, que son pruebas que se realizan con usuarios utilizando el programa en un entorno controlado, bajo la supervisión del programador.

Si finalmente se superan también estas pruebas, el programa ya estaría listo para ser mostrado al mundo. Pero como (todavía) no tenemos infornejos, cuando el programa salga a recorrer mundo, en realidad, habrá pasado las pruebas que haya pasado, pero no se habrá probado todo. Sabedores de esto, lo que se hace es liberar una versión beta, previa a la versión final, para que un grupo selecto (pero no escaso) de usuarios la prueben.

Hasta aquí la explicación de la enorme dificultad que tiene dejar un programa sin sus errores naturales.

El proceso de buscar los errores y corregirlos se llama depuración. La depuración es una fase que fácilmente puede ser más costosa que el desarrollo de una "primera versión" del programa.

Hemos visto que los programas necesitan depuración. Hemos visto que la depuración de un programa es tan costosa que muy probablemente no termine nunca. Ahora la pregunta es: ¿Quién hace la depuración del programa?

La pregunta es tan interesante e importante, que te la voy a plantear como pregunta de tipo test, con posible respuesta múltiple, para que la respondas antes de seguir leyendo:

¿Quién hace la depuración del programa?

a) El programador

b) El usuario

c) El cliente

d) Me la suda

Por si las dudas: el programador es el que hace el programa, el usuario es quien usa un programa ya hecho, el cliente es quien paga al programador para que le haga el programa que necesita, y la última opción está clara.

SOLUCIÓN DEL TEST:

La opción "d" no es ninguna broma, y tiene que estar ahí. En esos días en los que me levanto de la cama con un optimismo exultante, estimo que el porcentaje de usuarios de informática a los que se la suda cómo funcionan las cosas, quién hace qué, y las consecuencias de las decisiones que consciente o inconscientemente toman, debe de estar bastante por encima del 99%. La opción debe estar ahí para ellos.

Si has escogido únicamente la opción "a", significa que estás todavía en las nubes; que, si has leído lo anterior, lo has hecho sin aprovechamiento. La opción "a" hay que escogerla, porque el programador es el que sabe corregir los errores en el código. Pero la depuración consta de dos tareas: encontrar los errores y corregirlos. Se necesitan recursos para corregir los errores, pero también se necesitan recursos para encontrarlos, y lo que debes entender es que se necesitan cada vez más recursos para encontrarlos a medida que estos van siendo cada vez más difíciles de encontrar.

Por tanto, la respuesta correcta (realista) es el programador y... alguien más. Acepto "b", "c", o "b y c". ¿Cuál es la (importante) diferencia?

Bien, pues... ya hemos dicho que las versiones beta de los programas son para que las prueben usuarios. Los usuarios usan los programas, y cada uso del programa es una prueba. Así que lo acertado es pensar que los programas muy usados están muy probados, y que tengas esto en cuenta cuando estés valorando qué programa usar para eso que quieres hacer. Si no encuentras ninguno que te satisfaga, tal vez recurras a pagar por un desarrollo a medida: entonces, te convertirás en el cliente. Y acepto el cliente como respuesta porque, en cuanto el vendedor te haga entrega del programa que has pagado, te convertirás en su usuario. Esto significa que comenzarás a usarlo, es decir, a hacer pruebas. ¡Pero esto no te lo dijo el vendedor!

Cuando el vendedor entró por tu puerta con su flamante corbata, te ofreció hacerte una nueva aplicación o directamente te ofreció su aplicación, que se adaptaría perfectamente a tus necesidades, estaría totalmente testeada, sería completamente estable... en fin, el Valhalla hecho software, vamos. Nunca te advirtió de que el programa podría tener errores o dar problemas (como todos los programas); nunca te advirtió de que la depuración te la ibas a comer tú, con o sin patatas.

De hecho, esto es tanto así que muchas veces los vendedores te ofrecen uno de estos "probadísimos" programas de los que no tienen ni una primera versión funcional. En no pocas ocasiones, no se empiezan los desarrollos hasta no tener los pedidos, cosa ética y legítima cuando el cliente es conocedor de ello y de lo que esto significa, pero no en otro caso.

Conocí en cierta ocasión un vendedor que esto lo explicaba diciendo que (cito lo más textualmente que puedo recordar):

Nosotros no mentimos, nosotros decimos verdades anticipadas (Es decir, no es cierto ahora que tengamos el programa ya desarrollado, pero lo será en el futuro, cuando lo tengamos.).

En cualquier caso, tú tienes que saber que los programas tienen fallos, y lo que tú tienes que hacer a la hora de escoger un programa para tu uso es estimar cuántos fallos tendrá y qué importancia tendrán esos fallos para ti. Un programa muy utilizado probablemente (esto no es una regla general) tendrá menos fallos y de menor importancia que uno poco utilizado. Si los fallos son poco importantes, te bastará con saber que esto es "lo normal" para evitarte frustraciones personales y resignarte a vivir con ellos. Pero si son importantes para ti (porque afecten a tu negocio, por ejemplo), habrá que arreglarlos. Piensa entonces que si a tu coche se le fundiesen las bombillas sería malo, pero que no se las pudieses cambiar sería muchísimo peor.

Y recuerda que para corregir los errores en un programa, es necesario tener acceso a su código fuente.