Cuando el software retrasa la investigación

Las ciencias de la salud siempre han atraído mi atención, de hecho todos los años de un tiempo a esta parte paso por la fase de ver si empiezo una carrera relacionada o no. Hace unos meses me surgió la posibilidad de meter poco a poco la cabeza en temas de investigación relacionados con la biología, así que aproveché la oportunidad y procuro aprender todo lo que pueda y aportar todo lo que sé de otros campos, especialmente en el área de software.

Estoy muy sorprendido de los entornos que tienen que utilizar los investigadores y más sorprendido aun de que obtengan algún resultado con todo el tiempo que tienen que invertir en las herramientas:

Páginas web con decenas de opciones y campos

Herramientas de línea de comandos que no funcionan los días de luna llena ( a no ser que toques los fuentes o tengas la versión 10.5.3.2.6.7b)

Combinaciones de herramientas que solo funcionan en versiones específicas

APIs hechas sin conocimiento

y un largo etcétera de despropósitos….

Desde la óptica de una persona que viene del mundo del software y que es novel en el área de investigación, todo esto me parecía absurdo!!… sobre todo teniendo en cuenta que el software de simulación, de análisis… es la base fundamental para la investigación!! aun teniendo profesionales excelentes en un área determinada, si las herramientas les fallan es como mandarles a la guerra con una pistola de hace 50 años… no quiero pensar cuántos descubrimientos se nos han escapado (y se nos escaparán) por una deficiencia en los paquetes de software =(

Personalmente he visto algunas tendencias que creo que provocan estas deficiencias.

Los investigadores son los que se desarrollan su propio software. Por un lado admiro que aprendan por su cuenta e incluso que lleguen a una aplicación funcional… por otro… os diría que dejéis las manitas quietas y os dediquéis a lo vuestro O=) Hay miles de desarrolladores, product managers…que os darían una solución más óptima, más fácil de mantener, con menos errores, mejor usabilidad,… y un largo etcétera, porque es su especialidad, hacer producto que va a ser usado, que hay que mantener, que hay que corregir y que hay que modernizar . Una cosa es que alguien se haga una página web para su grupo de fans de pepito grillo o para una porra con los amigos. Otra muy diferente es que un proceso de investigación quede comprometido por la falta de calidad del software que se utiliza.

Un matiz… no digo que un investigador no tenga que tirar sus scripts o hacerse alguna herramientilla personal… me refiero al desarrollo de las herramientas fundamentales.

 

Herramientas de cuando matusalén hizo la comunión. Me resulta simpático cuando alguien afirma ‘XXX es el lenguaje para entornos de investigación YYY’ ¿Por qué¿ ¿Por qué hay que usar XXX?… si no tiene un API específica, ni fue diseñado para eso… ¿por qué ‘es el lenguaje’ o ‘la herramienta’? … En mi opinión es porque es el que usaron inicialmente los que se han metido en ese campo, porque posiblemente fue el primer libro que cayó en sus manos o el lenguaje que estudiaron en la carrera… nada más. En una organización que tiene que vivir de sus productos, éstos se actualizan, se utilizan herramientas más nuevas, se cambia el desarrollo a otra plataforma para modernizarlo. Esto a penas pasa en el software de investigación porque no se piensa en el software como producto.

 

Poco aprecio por los productos ‘comerciales’ Lo he notado en las conversaciones y en los foros… hay preferencia por la herramienta gratuita de comunidad antes que el paquete de software del proveedor X que esta especializado en eso. No he tenido la oportunidad de valorar la calidad de los paquetes comerciales, pero cualquier descarte irracional me parece un error. Estoy seguro de que habrá productos excesivamente caros… pero también los habrá que valen hasta el último céntimo de lo que se paga por ellos.

 

Desarrolladores sin experiencia en desarrollo de producto. Si vas a hacer algo que va a utilizar alguien que no eres tu y que tiene que mantenerse en el tiempo, vas a hacer un producto. Y si vas a hacer un producto y no tienes experiencia en ese campo… asume que tienes que aprender algo e infórmate!! No lo veas como una pérdida de tiempo, es una inversión que va a hacer que tu futuro producto sea mucho mejor para el propósito que tenías en mente…y eso es deseable, no?. En mi opinión, la opción de hacer un ejecutable regulero o una página que tiene un manual de instalación de 10 páginas… me parece bastante poco profesional. Aunque estamos en una realidad donde el desarrollo de software se ha pervertido bastante y muchos se consideran (y se promocionan) como desarrolladores, cuando todo lo que tienen a la espalda es el desarrollo de una app o una página web con una base de datos (yo he curado alguno que otro corte y no pongo q soy médico junior en mi currículum ;).

  OJO…. que si eres investigador en lenguajes de programación o en big data o en un área específica (de nicho) del mundo del software… desengáñate… tu no eres desarrollador de producto y también deberías recurrir a especialistas (o formarte). Dañará tu ego pero mejorará tu resultado 😉

Obviamente nadie hace las cosas de forma regular a posta (excepto los poco profesionales) y estos problemas que comento se basan en el desconocimiento de cómo hacerlas mejor. Pero me preocupa que las investigaciones no tengan el software adecuado simple y llanamente por inercia y porque ‘esto es así’ :/

De todos modos, estos problemas, son problemas que no sólo afectan a los investigadores, en cierta forma todas las áreas lo sufren (solo tienes que pensar en el último TPV que hayas visto ó en el último cajero que hayas sacado dinero…), podríamos decir que quitando algunas contadas excepciones… el software está envejeciendo a la misma velocidad a la que avanza la tecnología y a penas hay tiempo de reacción para evaluar cambios deseables o plantearse una migración. Todo es para ayer, no? =_)

Ojalá pudiese terminar el post con una brillante idea de cómo solucionarlo todo de un plumazo, pero no soy tan visionario! X)

Lo qu si sé es que todo cambio debe empezar por uno mismo, así que empecemos plateándonos cómo lo estamos haciendo y cómo nos gustaría hacerlo 😉

Personalmente creo en la autocrítica responsable casi como una religión. Una buena autocrítica (de esa que construye y te ayuda a mejorar para el próximo día/proyecto/iteración)… de ahí surgen muchas buenas ideas y necesidades que nos ayudan a evolucionar.

Happy hacking!!

David Salgado (@davidsb)

PD –> Por ejemplo: Pruebas, desde test unitarios a pruebas automatizadas, de carga, etcétera…. acostumbrarse a empaquetar la información en librerías en lugar de liberar ejecutables como si no hubiera un mañana, control de código, algo de usabilidad en el caso de web, pensar en arquitecturas distribuidas / entornos paralelos…