Mi rincón en Internet

Supongo que muchas personas estarán al tanto de la campaña que ha montado el Ministerio de Cultura, “Si eres legal, eres legal”. Entre otras cosas, han montado una página web en la que nos advierten de lo dañina y perjudicial que es la piratería.

Sin entrar a valorar esta campaña y lo que pretende, me chocó ver como “testimonio ganador del mes de diciembre” la siguiente perla:

Testimonio ganador del mes de diciembre

Me lo contaron en el colegio, entre y me bajé películas, me entraron virus y me tuve que cambiar el cpu porque los virus se metieron en el procesador, no os bajéis cosas, son gente que pone cosas malas dentro de los archivos y te roban tus datos, tus fotos, y todo!!!! Se legal FACILMENTE!!!

Tras una breve indagación, me he enterado de que este mensaje lo mandó un usuario con una intencionalidad totalmente satírica y burlesca (en varios sitios mencionan la anécdota).

Lo que me pregunto es si la gente que gestiona este sitio es tan incompetente ignorante como para dar crédito a un testimonio tan absurdo y claramente guasón o es que consideran que los ciudadanos somos idiotas y que nos creemos semejantes “testimonios”. No sé qué pensar.

Desde luego, lo menos que pueden hacer para que su mensaje sea tomado en serio es ser rigurosos. Con un alarmismo facilón como éste no creo que consigan tener mucha credibilidad.

En la literatura sobre desarrollo de “software” se escribe a menudo sobre un concepto con reminiscencias biológicas: el ciclo de vida del software.

A grandes rasgos, el desarrollo del software sigue unas etapas: se planifica (etapas previas de tomas de requisitos y análisis), se desarrolla (programación e implantación), se mantiene (arreglo de posibles fallos durante el uso del mismo, labores administrativas programadas, …), evoluciona (se agregan nuevas características si surge la necesidad) y, a veces, muere (se deja de utilizar el producto).

Lo habitual es que la etapa de mantenimiento sea la más larga, pero no debería ser la más costosa económicamente. Sin embargo, existes numerosos sistemas en lo que esto no es así.
¿Han trabajado alguna vez con el típico programa con muchos fallos pero que, sin embargo, se utiliza desde hace mucho tiempo y no hay planes para sustituirlo? ¿Les suena la situación cuando todo el conocimiento de “las tripas” de una aplicación se deposita en muy pocas personas (incluso en una sóla)? ¿Utilizan algún programa que sólo funciona en algunos entornos muy específicos con unas versiones muy concretas del sistema operativo y otras aplicaciones? ¿Se gasta su empresa un dineral en personal subcontratado para que este programa siga malfuncionando?

Todos estos son los síntomas del “software insostenible” (la nomenclatura es propia). Programas y aplicaciones que no han sido bien gestionados y se han escapado de las manos de los que los diseñaron, los programaron, los mantienen y de los que pagan todo esto, el cliente final.

Al final nos encontramos con un dinosaurio software, lento, grande y arcaico. Los usuarios lo odian porque nunca acaba de ir bien, los responsables de área lo odian porque se lleva muchos recursos presupuestarios, los desarrolladores lo odian porque es asqueroso trabajar con el código enmarañado y mil veces parcheado, …

Lo peor en estos casos es que la solución más obvia, que es rehacer la chapuza, o al menos, dedicarle un buen tiempo para poner orden y concierto, sale muy caro (además, no hay garantía de que la nueva versión sea buena). Pero también sigue siendo muy caro el mantener la aplicación. Un buen dilema económico.

Algunas causas:

• Mala planificación o diseño previo.
  Frecuentemente las tomas de requisitos son muy vagas o imprecisas. Esto conlleva hacer cambios importantes cuando el programa ya está en producción, con los riesgos que esto conlleva: prisas, código rápido y sucio, desintegración entre las distintas partes del programa, …
• Uso de una herramientas/lenguajes inadecuados y/o obsoletos.
  Algunas herramientas (lenguajes de programación, entornos de desarrollo, etc) son muy permisivas con las malas prácticas al desarrollar software. Dejan una libertad de actuación al desarrollador que puede ser perjudicial al no forzar una buena organización del trabajo y del código.
• Mala organización del personal.
  Personal novato al que se le pone a trabajar sin una adecuada formación y supervisión en clientes finales, alta rotación del personal, jefes de proyecto/analistas sin vocación técnica que no revisan el código que se produce, …
• Clientes mal acostumbrados.
  Muchos clientes quieren las cosas para ya, y no siempre es posible hacer algo rápido y bien. Si una mejora requiere un estudio y análisis, así se le debe comunicar al cliente, y no ponerse a picar código como locos.

Podría seguir enumerando más errores, pero no merece la pena. ¿Existe alguna solución para este desaguisado?

Probablemente para los sistemas existentes sea difícil encontrarla, pero hay que aprender de los fallos:

• Sres. contratantes: no fuerce a los profesionales que contrate. Si le dan unas estimaciones, respételas, no son gratuitas.
  Desconfíe de empresas de desarrollo o consultoras con mucha rotación de personal. Infórmese antes de cómo se trabaja en ellas. Los “obreros del software” somos también muy importantes, no sólo los encorbatados que van a presentar y vender el producto.
• Sres. contratados: no sucumban a la tentación de dar plazos cortos, ni de presentar presupuestos muy bajos. Sean realistas.
  Cuiden y formen bien a sus “picateclas”, pero supervisen su trabajo: no para sancionar, sino para mejorar. Hagan una buena ingeniería y planificación, no se “aten” en exceso a una tecnología.

Barrapunto es un sitio web muy conocido donde se discute y debate sobre noticias relacionadas con la tecnología y campos afines.

Esta mañana leía un titular (¿iPods de 500.000 gigas?) y en el texto se decía: “desarrollan un interruptor microscópico que modifica el tamaño de las moléculas“, enlazando a la noticia original en inglés.

Como titulado en Químicas que soy, me sorprendió mucho esto de modificar el tamaño de las moléculas, así que leí el artículo original un poco por encima, encontrándome con el texto “they had developed a molecule-sized switch”, que viene a ser algo como “han desarrollado un interruptor de tamaño molecular”. Eso es otra cosa muy distinta.

Conclusiones:

• El periodismo tecnológico a veces es un poco cutre y no se contrastan las noticias. Hace mucho tiempo que se está investigando con la posibilidad de utilizar las moléculas (orgánicas, como las proteínas) como soporte de información. No estoy al día de los avances en este campo, pero dudo que lo que han logrado estos investigadores sea tan definitivo como parece (por favor, corríjanme si no estoy en lo cierto).
• Cuando se publica algo que no ha escrito uno mismo, al menos hay que leerse las fuentes. No pasa nada si se traduce algo mal, todos nos equivocamos, pero cuando el escrito pasa por varias manos el error no debería propagarse.
• Finalmente: ¡qué bien lo han hecho los de Apple!. Realmente son unos genios del marketing. Dudo que esta noticia hubiese tenido la más mínima relevancia si no se hubiese mencionado en el artículo el cachivache de Apple.
  Da igual que este reproductor portátil tenga las limitaciones que tiene: es un “objeto de deseo” y su sóla mención en un texto parece que hace más atrayente su lectura.

Me contaban el otro día una anécdota nada divertida. Cierta persona tenía que rellenar un formulario con un montón de campos para una administración pública, había que especificar hasta 80 centros de trabajo, más los datos comunes, etc. En total, unos 100 campos.

Al pie del formulario había dos botones: “Validar y enviar” y “Limpiar”. La persona que me contó este caso, no muy ducha en cuestiones informáticas, interpretó que “Limpiar” se refería a una especie de corrector ortográfico o algo así, así que lo pulsó.

Mágicamente, el formulario se borró por completo, tirando a la basura más de una hora de trabajo de esta persona. Para echarse a llorar.

Y yo añado: y para matar al diseñador o programador de ese formulario.

1. Los botones de un formulario pueden rotularse. ¿No estaría más clara la función de ese botón si estuviese rotulado como “Borrar todo” o algo así?
2. Regla de oro cuando se diseña un interfaz de usuario: si una acción es potencialmente destructiva, pide al usuario confirmación antes de proceder a ejecutarla.
3. Opinión más personal: ¿para qué se necesita un botón de “limpiar” en un formulario? Sinceramente, no le veo ninguna utilidad.

En las pasadas semanas Microsoft nos ha sorprendido con dos noticias bastante inusuales en ellos: la publicación de las especificaciones técnicas de los formatos de archivo de Office y la apertura del código fuente de sus programas.

A primera vista puede sorprender este cambio de rumbo, pero pensándolo un poco más, en mi opinión, se ve claramente la intención de Microsoft: evitar más sanciones por prácticas monopolísticas y conseguir que su nuevo formato de documento, Open XML, sea aprobado por la ISO* (a finales de marzo de 2008 se tomará una decisión).

¿Qué puede suponer para los usuarios finales esta decisión de Microsoft? En principio, son buenas noticias, puesto que los programas competidores de Microsoft Office pueden mejorar mucho conociendo exactamente cómo es el formato de los archivos de Office. Hasta ahora este conocimiento se hacía por ingeniería inversa, generalmente, es decir, adivinando o suponiendo cómo era este formato.
Si los programas ofimáticos mejoran su capacidad de tratar con los archivos de Office será algo bueno para los usuarios: no tendremos que estar “atados” a los productos de Microsoft.

En la práctica puede que este regalo no sea tan bueno: ahora Microsoft tiene la excusa perfecta para embrollar a voluntad sus especificaciones sin poder ser acusada de monopolista, puesto que, a pesar de ser públicas, estas especificaciones son tan complejas y extensas que pocos desarrolladores o companías podrán implementarlas con la rapidez necesaria para no perder usuarios. Por otra parte, si todos los productos ofimáticos fuesen capaz de tratar con el formato de Microsoft, esto supondría la desaparición total de otros formatos (en realidad esto ya es casi así: pocas personas conocen otros formatos que no sean los omnipresentes .doc, .xsl, .ppt y familia).

En un mundo ideal, todas las compañías de software tratarían de desarrollar productos compatibles, y antes del Open XML de Microsoft ya teníamos el Open Document Format, un formato de archivos ofimáticos libre, estandarizado y apoyado por multitud de compañías y organizaciones.

*: Organización Internacional para la Estandarización