La verdad en diez palabras

Me encantan las frases motivadoras, los slogans (no, eslóganes), que pretenden ser enseñanzas demoledoras de como hay que ser, de como hay que pensar, de como hay que actuar. Me fascinan. Ejercen sobre mí el mismo atractivo que las soluciones sencillas y cortas, y no me dejo entristecer por el hecho de que tanta simplificación se haga al precio de la eficacia e incluso de la utilidad (y ni hablar del valor de verdad).

Pero mi gozo con las frasecitas aumenta con son atribuidas a alguna luminaria. Y en particular, cuando la atribución es falsa, o, al menos dudosa (así como Galileo es el santo patrono de los chiflados autocompasivos, Einstein podría ser el santo patrono de los amantes de las citas ridículas). Por eso, lamento que mi eslogan preferido ("lo único constante es el cambio", o algo así) no haya sido atribuido a Einstein. De todas maneras, no pierdo las esperanzas.

Aunque la frase "lo único constante es el cambio" nos suene a verdad de Perogrullo, actuamos como si esto no pasara, como si pudiéramos elegir que las cosas no cambien. En una profesión que gustamos de vender tan adicta al cambio vertiginoso que nosotros como nerds-geeks-geniales manejamos como nadie, gustamos de perpetuar algunos conceptos (como el de desarrollo en cascada, por ejemplo). Así, decimos cosas que han sido verdad hace millones de años (bueno, tal vez exagere) sin detenernos a pensar si son ciertas hoy.

Puedo entender uno de los motivos para este problema: uno no puede estar revisando permanentemente todo lo que ha aprendido. Y no es un problema que así sea, particularmente cuando hablamos de los conceptos de la base teórica (los BTrees andan más o menos igual desde hace unos cuantos años, por ejemplo), pero no estaría mal intentar recordar que las recetitas tecnológicas cambian con facilidad.

Por recetitas tecnológicas entiendo un tipo de pequeños mandamientos taxativos sobre como implementar, o sobre que cosas deben hacerse y que cosas no, que suelen propagarse a través de las versiones de una base de datos, sistemas operativos, lenguajes de programación y cosas así. Por ejemplo, "un cursor explícito es siempre más rápido que uno implícito", o "tenés que poner tus DML en procedimientos almacenados en la base", "tenés un full table scan, agregale un índice" y uno de mis preferidos: "no concatenes strings directamente, usá un StringBuffer".

El problema con estas recetitas tecnológicas es que suelen ser falsas, o, al menos, tienden a desactualizarse con facilidad (de las mencionadas, algunas fueron ciertas en algún momento y otras han sido siempre falsas o, al menos, discutibles). Más o menos me acostumbré a ellas y puedo explicar pacientemente a quien lo requiera por qué una recetita de esas es un mito (o puedo mandarlo a la entrada correspondiente de la wiki, para ser más honesto).

Si bien suelo ser paciente, el otro día perdí la paciencia. Un tipo que estaba tratando de convencerme de que debía comprar (que la empresa debía comprar, mejor dicho) un software propietario para inspección de código que no hacía mucho más que PMD, Checkstyles y Macker combinados me mandó una presentación de su maravilloso (según él) y caro (según el presupuesto) producto. En la segunda hoja del primoroso powerpoint los fabricantes de la herramientas tranquilizaban al lector diciendo que su herramienta era capaz de impedir que módulo, programa o similar que tuviera una query que hiciera un full table scan fuera a producción. Y luego, que detectaba problemas de performance como la concatenación de Strings en lugar del uso de StringBuffers. Esa presentación me convenció: la herramienta en cuestión hacía más cosas que la combinación de PMD + Macker + CheckStyles, el único problema era que las hacía mal.

De alguna manera, se les olvidó revisar sus conceptos sobre la performance de herramientas formados hace unos cuantos años, aunque pusieran en la presentación de su herramienta que "lo único constante es el cambio" (o algo así). Creo que estoy llegando a darme cuenta por qué me gustan los eslóganes: nos hacen pensar que actuamos como nos gustaría actuar, no como en realidad actuamos.

De esta anécdota surgió algo interesante. Nuestro embrionario detector de camelos informáticos (inspirado, claro, en el de Carl Sagan, y cuyo nombre más formal podría ser manual de procedimientos de verificación y validación de CMMI L3) incorporará algunas guías sobre como tratar las frases cortitas y taxativas no autoevidentes que parecen confiar en características ocultas o en internals de la tecnología: en el mejor de los casos, como algo que fue cierto alguna vez o es cierto en una versión muy específica y que debe tratarse con cuidado fuera de un ambiente muy definido (por aquello de la inevitabilidad del cambio). En el peor de los casos, como basura sin sentido.