Pus sí, otra vez arroz. Qué quiere usted, a mi la certificación así solita ya me produce indigestión, que me intenten convencer de la necesidad de certificar las metodologías ágiles de desarrollo de plano me provoca úlceras gástricas.

En LinkedIn, en el grupo de eXtreme Programming han comenzado un debate que, pensándolo un poco, parecía inevitable: “Dave Nicolette: Uncertain about certs“. Aunque parezcan inconciliables, hay personas que creen que crear un certificado para desarrolladores “extreme” es una excelente idea, o peor aún, que es una necesidad.

Quizá sea buena idea recordar que el desarrollo ágil valora:

Individuos e interacciones sobre procesos y herramientas
Software funcional sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contrato
Respuesta al cambio sobre seguir un plan

Los firmantes del manifiesto creemos que mientras exista valor en los primeros a la derecha, podremos valorar los de la izquierda.

La pregunta obligada sería: ¿Es ágil un certificado como “desarrollador ágil”?

Sin llegar a los doce principios del manifiesto, quedémonos ahora con los principios de valor:

Individuos e interacciones sobre procesos y herramientas

Un certificado implica un proceso y una serie de herramientas de evaluación, que aunque sean buenas, no nos garantizan la calidad “ágil” de un desarrollador. ¿Qué le vamos a medir: su capacidad de trabajar en grupo, su creatividad, su habilidad con los lenguajes de programación, su conocimiento de patrones y UML?

Recuerdo una explicación de G. Bateson acerca de los esquizofrénicos. Bateson cree que no existen enfermos de esquizofrenia, sino familias enfermas. Si el “enfermo” es aislado de su familia, con frecuencia desaparecen los síntomas. Con los desarrolladores pasa algo parecido, yo creo que no existen desarrolladores ágiles, sino equipos ágiles. La agilidad implica colaboración, trabajo en equipo, negociación y aprendizaje continuos. Un individuo aislado puede tener buenas prácticas, pero no puede ser “ágil” así nomás, así solito.

Si la agilidad requiere de los equipos, ¿a quién vamos a certificar, al equipo o a los individuos?

Software funcional sobre documentación exhaustiva

Siendo congruentes, ¿no deberíamos más bien evaluar a los desarrolladores por su desempeño en el equipo y no por su fatua currícula? Cada que buscamos un candidato para formar parte de nuestros equipos, somos muchos los que valoramos mucho más la entrevista o el periodo de prueba que las verdades y mentiras que la gente debe poner en sus currículos. ¿Un certificado en metodologías ágiles será la diferencia?

No puedo entender que al software, a nuestro producto, nuestro entregable, a nuestro trabajo le exigimos la pragmática prueba de la funcionalidad mientras que con nuestros colegas nos conformamos con la impersonal presentación de un papelito sellado y con holograma.

Colaboración con el cliente sobre negociación de contrato

Pues sí, los desarrolladores ágiles tiene que colaborar, con el cliente y con su equipo. Por muchos certificados que tengan, si no encajan en el equipo, no podrán aportar valor.

Si contratamos a un desarrollador por su certificado, negociando el contrato respecto a esas pomposas credenciales, no deberíamos quejarnos después si el individuo no es el mejor compañero de trabajo, no lo contratamos por lo que hace, sino por lo que alguien más dice que sabe hacer.

Cuántos excelentes desarrolladores conoce usted que son médicos, veterinarios, matemáticos, o vaya usted a saber que otras certificaciones más, y sin embargo, son increíblemente buenos en lo que hacen. Por ponerle un par de ejemplos, mis colegas más cercanos son un flautista (profesional, con certificado y toda la cosa) y un biomédico (también certificado y sellado por la UNAM), ambos son excelentes desarrolladores de software.

Respuesta al cambio sobre seguir un plan

Y bueno, los planes… Sabe usted, uno de los mayores problemas con las carreras relacionadas con la computación y la informática es que para cuando los estudiantes terminan su carrera, el plan de estudios ya está terriblemente avejentado. Lo que hace cuatro años era toda una vanguardia, el día de hoy puede ser, o bien un conocimiento básico o más comúnmente, una anécdota como las tarjetas perforadas.

Los responsables de andar certificando “agilistas” deberían entonces adaptarse siempre al cambio, lo cual implica que su certificado certificaría distintas cosas cada vez que se expide, lo que nos deja con la otra pregunta obligada ¿Qué certifica un certificado de “desarrollador ágil”?

Desde niños nos enseñan a ser creativos, a ser originales. Nos educan a no copiar a los demás y a tratar de reinventar el hilo negro todo el tiempo, aunque sólo sea ponerle motitas de decoración para distinguirnos de los demás. Con el tiempo, esas enseñanzas serán aprovechadas por la mercadotecnia que seguirá machacándonos lo mismo: “se original, distínguete de los demás, cómprate un…”

Pero resulta que algunos crecemos y terminamos en medio del desarrollo de software o en la arquitectura o en la ciencia o, para acabar pronto, en la vida real. Una vida en la que ser creativo es importante, pero ser práctico lo es mucho más. De nada nos sirve reinventar mil veces la rueda, a veces sólo necesitamos usarla y lo más razonable será tomar la rueda que alguien más, o muchos alguienes más ya inventaron y perfeccionaron; a veces es casi una rueda lo que necesitamos, entonces nos ahorraremos mucho trabajo comenzando con una rueda y modificándola, que haciendo todo desde el principio y sin ayuda. Y en algunas otras ocasiones, con mucha suerte, lograremos mejorar un poco el diseño de la rueda y podremos publicar nuestra humilde aportación a la humanidad. En cualquiera de estos casos, más nos vale saber qué es lo que ya se inventó, así nos ahorramos mucho trabajo, horas de sueño y bastante dinero.

Uno de los pioneros en esta didáctica de la copia, del refrito y del más de lo mismo fue un arquitecto visionario llamado Christopher Alexander, mucho más conocido en el mundo del desarrollo de software por su libro Pattern Language, inspirador de lo que ahora se ha convertido en el BUM de la arquitectura y el desarrollo de software.

Christopher Alexander no sólo nos enseñó que es más fácil organizar las soluciones ya probadas a problemas típicos en “patrones”, lo más importante es que nos desenseñó a pretender ser originales a toda costa. Nos mostró que es posible y más valioso ser creativo reusando lo que otros han hecho. Hacemos las cosas más fáciles y con más eficiencia si nos aprovechamos de la experiencia de los demás.

Finalmente, lo que Alexander nos mostró no es tampoco muy original. Es la historia de la ciencia y de la tecnología en la humanidad. Nuestro conocimiento se cimenta siempre en el conocimiento anterior. Pero nadie había dicho las cosas tan claritas como aquel viejo arquitecto que, como los jugadores de Go, se dedicó a formar un compendio de Josekis de la arquitectura. Al igual que en el juego, los patrones no son para no pensar, sino para que podamos concentrarnos en la obra completa, dejando los detalles de la implementación en manos de la experiencia acumulada de generaciones de jugadores, arquitectos, desarrolladores, científicos y profesionales de todo tipo.

Una de las experiencias más agradables en el trabajo de desarrollo de software es cuando nos enfrentamos a usuarios inteligentes que saben lo que quieren. Que lo tienen tan claro que incluso han creado una complicada aplicación en Excel. No hay como trabajar con un demo funcional.

Para la mayoría de los programadores, Excel es sólo una calculadora grandota, además de una desgracia para el gremio, por haber permitido que los usuarios lo utilicen como base de datos, procesador de texto, formador de pre prensa, plataforma multimedia y vaya usted a saber cuántas cosas más.

¿Qué es eso que ha permitido a los usuarios comunes y corrientes crear aplicaciones tan sofisticadas con una hoja de cálculo? No se suponía que ellos son unos verdaderos analfabetas computacionales, sin la más pichicata idea de lo que es un lenguaje de programación… Pues no, resulta que nuestros agnósticos usuarios son los programadores del lenguaje más utilizado en mundo: el ubicuo lenguaje de las fórmulas de Excel.

La respuesta pasa sin duda cerca de las ideas de Martin Fowler y su exploración de los DSL. Excel es un sistema que les permite a los dueños del domino hacer sus propias aplicaciones, les permite experimentar y sobre todo, les ahorra el tortuoso proceso de platicar con el equipo de expertos en Desarrollo de software.

Quizá los programadores son buenos programando, pero suelen ser muy malos tratando de adoptar la cultura de negocios de los usuarios. Los usuarios quizá no son los más dotados en habilidades computacionales, pero saben qué es lo que necesita la organización, cómo se hacen los negocios y qué es lo que necesitan obtener de la máquina.

El sueño de Fowler es tener un DSL (Domain Specific Language) o cualquier otra cosa que permita a los usuarios crear aplicaciones sin la interferencia de los programadores. Excel no es un DSL, pero ha permitido, desde sus orígenes, que los usuarios se independicen un poco del staff de desarrollo, y se está convirtiendo en una fuente de inspiración para los que intentan devolver el proceso de creación de aplicaciones a los expertos de negocios: los usuarios.

Personalmente no estoy tan seguro de que soluciones como Excel y los DSL sean la opción más viable en el mundo de los negocios. Para algunos usuarios sin duda son la mejor opción, pero no todos son expertos en hojas de cálculo. Otra manera de enfrentar el problema de la brecha cultural entre los negocios y las IT’s es la creación de equipos de desarrolladores entrenados, más que en lenguajes de programación, en adquirir contextos culturales (Erick Evans).

En cualquier caso, las dos alternativas parecen sustentarse en la creación de puentes y embajadores de un extremo al otro, ya sea personas de negocios creando aplicaciones y manejando algún lenguaje de programación (Excel o DSL’s) o desarrolladores hablando el lenguaje de negocios que le han enseñado los expertos de dominio y descubriendo junto con ellos la manera en la que se creará la aplicación.

Lo importante de estos enlaces entre los negocios y el software es que no se trata ni de metodologías ni de tecnologías de ningún tipo, sino de seres humanos. Son personas hablando con personas. Al final de todo, la solución está en la comunicación humana, en la eficiencia con la que podemos llegar a interpretarnos y malinterpretarnos unos a otros.

Hace poco tuvimos que realizar una aplicación express, o sea, la teníamos que desarrollar en menos de un día, la probarían al día siguiente, la usarían dos días después y la mandarían a volar al tercer día. De hecho, la idea original de los usuarios era usar Excel y ni siquiera llamar a la gente de desarrollo.

Versionar un “proyecto” que ni a proyecto llega nos pareció, en ese momento, una buena práctica que podíamos ignorar. Recordé entonces que el mismísimo Kent Beck había hecho algún código sin pruebas unitarias, así que, escudado en el pragmatismo más vil, decidí dar mi aval a no crear un repositorio en el servidor de versionamiento.

Pasaron muchas cosas, la primera fue que teníamos razón, no necesitábamos crear un repositorio de versionamiento, la aplicación se terminó, se probó, se autorizó, se colocó en producción, nunca se utilizó y el código no vale ni de buen ejemplo. Para acabar rápido, fue una pérdida de tiempo.

Pero la duda sigue allí, el casi remordimiento de haber programado a capela, sin paracaídas, como trapecistas sin red.

A toro pasado, y por más vueltas que le doy, no consigo justificar una mala práctica tan elemental, a pesar incluso de que se tratara de un programa tan simple y sencillo. No es que nos hubiese salvado la vida, acá entre nos, si algo hubiese pasado, volver a empezar y programarlo todo desde cero no habría llevado mucho tiempo. El punto no es ese, sino la tolerancia a las malas prácticas (ya ve usted, la tolerancia no siempre es buena).

Tampoco me quiero poner de fundamentalista, sigo pensando que el servidor de versionamiento no tenía que utilizarse en algo tan pequeño, un poco de pragmatismo no nos viene mal aquí. Pero bien podríamos haber creado un repositorio local, en la misma máquina. Aunque fuera sólo para tener un super “undo”. Terminado el proyecto, se eliminan los archivos de código y el repositorio y es como si nada hubiese pasado. Un repositorio local no es una infalible red de seguridad, pero al menos de rodillera funciona.

Hay buenas prácticas que son tan elementales que podríamos llamar radicales, no en el sentido de la intolerancia, sino en el sentido de que son la raíz, el fundamento o cimiento para todas las demás. Versionar es sin duda una buena práctica radical.

Hace unos días sucedió algo que escandalizó al pequeño mundo del desarrollo de software con metodología XP.

Si usted conoce de metodologías ágiles, el nombre de Kent Beck seguro le dice mucho. Kent fue el creador de lo que conocemos ahora como Extreme Programming o XP, una metodología de desarrollo de software inscrita en el contexto ágil y una de las más agresivas en cuanto a velocidad se refiere. La metodología XP, como cualquier conjunto de lineamentos de cómo se hacen las cosas, tiene muchas recetas que “deben” seguirse a pies juntillas, por ejemplo: programar en parejas, refactoring continuo, y desarrollo dirigido por pruebas (Test Driven Development TDD).

El TDD exige que los programadores no escriban código de funcionalidad si antes no han escrito pruebas unitarias que validen el código que se escribirá. La idea es bastante directa: De un requerimiento funcional obtenemos una responsabilidad atómica del actor (clasificador, clase, etc.) que estamos modificando o creando, basados en esta responsabilidad escribimos el código que usaría esta funcionalidad, un código que además evalúa que la funcionalidad en cuestión haga lo que tiene que hacer. Éste código es la prueba unitaria, que funciona como documentación y ejemplo de código. Con la prueba unitaria programada, ahora tenemos que escribir el código para que la prueba tenga sentido semántico, o para que compile, en términos más directos. Cuando el código compila, podemos pasar a la parte en la que programamos lo necesario para pasar la prueba, y según el TDD, sólo debemos programar el código necesario para pasar la prueba. Si nos damos cuenta de que nuestra prueba no es suficiente para garantizar la funcionalidad que queremos, hacemos otra prueba y repetimos el proceso. De esta manera obtenemos un código probado que sólo hace lo que tiene que hacer -recordemos el viejo principio de que el código que nunca falla es el código que nunca se escribió.

Pues resulta que Kent Beck, como todo gurú, como cualquier padre de familia incluso, no parece tener el derecho de decir que a veces es posible, incluso aceptable, no seguir las reglas que él mismo escribió. En su blog personal, Kent escribió, aunque para muchos parece más bien que confesó, había escrito parte del código de JUnit Max sin escribir pruebas; o sea, que escribió a capela y sin paracaídas, lo cual, acá entre nos, es algo que hacemos todos los partidarios de la XP y del TDD, aunque no todos se atreven a reconocerlo.

El problema que yo veo en las exaltadas manifestaciones de rechazo a la publicación de Kent no es que el gran gurú se nos esté rajando, que no es el caso, sino que los partidarios de las metodologías convierten a estas en verdaderas ideologías fundamentalistas que derivan en fanatismos como los que observamos en las religiones y los nacionalismos. Una metodología no debiera ser nunca inflexible, o dogmática, mucho menos si se supone que es “ágil”, sin embargo, parece que los partidarios de la XP son tan susceptibles al fanatismo como lo fueron los lúmpenes al nazismo.

Las razones para no seguir a ojos cerrados el TDD pueden ser muchas, las razones para volverse un recalcitrante fanático de la XP no existen. Y lo que pasó con la XP y Beck no es muy diferente de lo que ha pasado con tantas y tantas ideas convertidas en manuales de Carreño por la falta de criterio de sus seguidores. Me atrevo a pensar que fue lo mismo que pasó con muchas religiones, con la aclaración de que en las religiones fue el fanatismo el que le ganó a las ideas.

Ya está demasiado de moda esto de la influenza y en México ya no se puede hablar de otra cosa, así es que le hablaré de lo mismo. Ni modo, se amuela.

Resulta que en este país, donde los puestos de los funcionarios de salud se deciden en una comida entre cuates con el presidente o el gobernante en turno de prebendas, las cosas ya se pusieron color de hormiga, precisamente, porque nuestros inteligentes y preparados funcionarios no tienen la más remota idea de lo que se debe hacer.

Además de favorecer un uso indiscriminado del tapabocas, objeto que ya debería incluirse en los catálogos de Gucci de adornos personales, ahora en la Ciudad de México, el carnal Marcelo, ese oligofrénico sin freno que nos gobierna, tuvo la genial idea de obligar a los choferes de transporte público a usar tapabocas y guantes, eso o les quitan el vehículo.

Sólo a las incompetentes autoridades capitalinas se les pudo ocurrir algo así. Si en los guantes de los choferes se acumulan un montón de partículas virales y otros bichos, eso es lo de menos, lo importante es que no se les arruine el manicure con el alcohol y jabón que deberían usar para desinfectarse las manos. Los virusitos podrán seguir su tranquilo camino de usuario y usuario a través del dinero o de los mismos guantes de los choferes.

Respecto a los tapabocas, nada mejor que un caldo de cultivo a la altura de la nariz para que las cosas mejoren. ¡Usted nomás imagine la cantidad de alimañas microscópicas que se van a acumular en los tapabocas después de una jornada de trabajo! Hay que ser demasiado ignorante y falto de sentido común para andar girando esas ordenanzas.

Pero las cosas no paran allí, tenemos la prohibición de abrir a los antros, bares y restaurantes de esta ciudad, para que la gente, además de gripienta, ahora ande del tingo al tango buscando comida, y es que, aunque los gobernantes no lo crean, los habitantes de esta ciudad también comen y también trabajan, y a veces, casi nunca según ellos, uno tiene que comer cerca del lugar de trabajo y uno no trabaja cerca de donde uno vive. Pero eso al carnal no le importa, ni eso ni tener toda la ciudad hecha pedazos, con agujeros por todos lados y maquinaria sin trabajadores. Porque usted no está para saberlo ni yo para contárselo, pero los trabajos en las obras viales sólo se hacen una vez por semana y eso es así desde antes del teatro éste de la influenza.

En fin, que aquí las cosas van de mal en peor, no por culpa de los virus ni de los cerdos, sino de los estúpidos gobernantes y las influencias que tienen para colocar, en puestos importantes, a unos retrasados mentales que no debieron nunca obtener un título universitario (ya ve usted un ejemplo de porque no creo en las certificaciones).

Para terminar, y para contrarrestar un poco este consumo irracional de tapabocas, le invito a dejarse la cara en paz, lavarse las manos frecuentemente, dejar de tener miedo a lo menso y ocuparse de cosas más importantes que no sean sólo esta mugrienta super gripa.

Y si usted es de esos necios que seguirán usando su disfraz de ninja de quirófano, le pido sólo que sea original y se haga usted mismo un tapabocas con Puca, Bob Esponja, el escudito del América o lo que le de la gana. O de plano, si quiere, póngase una máscara del santo, un pasamontañas como el sub o un elegante casco de Dart Vader

Actualización: El retrasado mental del presidente, en un acto de irresponsabilidad total, acaba de decir que todas las actividades no escenciales se suspenderán del 1° al 5 de mayo… supongo que para asegurarse de que, además del problema epidemiológico, ahora tengamos un inmanejable problema económico.

Estaba yo de curioso, viendo que se puede ver en aNobii, un sitio social para gente que le gusta leer y presumir lo que lee. En la sección de estadística de su “librero” podrá usted encontrar una pequeña sección de los libros y páginas totales que ha leído por año. En cuanto llegué al cuadro mencionado, hice un par de cuentas rápidas y pensé “¡Zaz! Este año he leído muy poco, tengo que leer más… lo que son los numeritos” y sí, lo que son los numeritos. Nunca en mi vida me había preocupado por cuanto leo, leía y punto, y de pronto, sin darme cuenta, ya estaba yo dándome cuotas de productividad lectora.

El aparente y esquivo problema se soluciona rápido, mandé a la goma la curiosa estadística y me prometí leer tanto como necesitara para sentirme a gusto, relajado, contento, desvelado, etc. y no lo necesario para cumplir una cuota de productividad. Los lectores, al menos algunos, no leemos libros por minuto, sino emociones por libro, que son dos “medidas” muy, pero muy distintas.

¿Por qué de pronto, al ver una estadística, nos vemos atrapados en una competencia contra quien sea, contra nosotros mismos si es necesario? ¿Qué es lo que nos impulsa a la competencia? Es como si las carreritas nos fuesen tan naturales que no podemos evitarlas. Pero también parece que esa “naturalidad” es una moda de estos tiempos. Queremos medirlo todo, saber cuánto cuesta todo, cuánto tarda, cuánto se usa. Queremos medir tantas cosas que, cuando nos ponen algo que se parece a una métrica, de inmediato la adoptamos y nos alineamos a ella.

No va mal medir las cosas, yo mismo soy un promotor del uso de métricas para casi todo, pero ese casi es muy importante, sobre todo lo es en aquello que no puede ni debiera ser medido. No podemos medir la confianza en la gente, la tristeza, la alegría, no podemos medir aquello que tiene que ver con nuestras emociones (las razones son muchas, y son cuento de otro post). Los libros, la música, los besos, los abrazos y otro montón de cosas tienen que ver, precisamente, con esas emociones inmensurables. Creo que es un error medirlo todo, y los sitios sociales son unos promotores espectaculares de este error. De pronto, medimos cuántos amigos tenemos, cuántos contactos tenemos, cuántos mensajitos nos ponen en Facebook, cuántos libros leemos, cuántas páginas leemos, como si nuestra calidad personal se midiera de esa manera tan cruda, tan reducida.

Pero no es culpa de los diseñadores de esos sitios, de hecho, ellos lo han puesto así, seguramente, porque nosotros, los usuarios, los seres humanos en general, así somos. Nos gusta medir, nos gusta compararnos, sentir que somos mejores a otros, que hemos mejorado con respecto a otros tiempos. ¿Qué es “más grande”, estar triste o estar asustado? ¿Qué es “mejor”, leer un libro que nos conmueve o reventarnos los ojos con un tratado de espeleología? Todo depende de a quién hace las preguntas, de a quién y de cuándo, y pasará a menudo que no importando el quién y el cuándo, no sea posible responderlas.

Las métricas están bien para saber a qué velocidad va el auto en el que viajamos, para saber cuántas líneas de código puede producir un equipo en un proyecto, cuánta energía eléctrica consumimos, etc. Allí están bien, midamos productividad laboral, pongamos números en la rentabilidad de un proyecto o de una empresa. Las métricas pueden ser útiles o pueden ser la forma más rápida de perder el placer. Las métricas nos acercan a los procesos, pero nos alienan de las personas.

La moraleja del cuento, que en este caso va más para mí que para usted, es que no podemos medir aquello que es inherente a las personas. Incluso en un ambiente laboral, lleno de pizarrones de productividad, hay cosas que no se miden, que requieren seres humanos que las interpreten: Cuando un miembro del equipo se siente excluido, no hay métrica que nos informe del problema, somos nosotros y nuestra intuición, mala o buena, los que debemos detectar el problema y buscarle solución, una solución que seguramente no pasará por las gráficas de productividad.

Después de mis últimos comentarios acerca de la ciencia, no dudo que alguno lector piense que soy uno de los enemigos personales de las academias y universidades. Lamento no darle toda la razón a tan perspicaz lector, tengo mis problemas con la estructura académica, sobre todo con la sobrevaloración de los certificados (títulos y anexos) y con el fanatismo cientificista, pero la ciencia sigue siendo uno de los puertos más agradables por los que he pasado. Comencé, hace muchos años, una inexistente carrera científica en las áreas biológicas. Los caminos de la vida, sin embargo, son como los de la isla de Ítaca.

Estaba yo terminando de dar mi clase (torturo ocasionalmente a unos chamacos con algo de matemáticas). Un doctor me detuvo en el clásico pasillazo, platicamos un poco de los alumnos, de los cambios en el instituto y sin saber cómo, llegamos al tema que me llevó, hace muchos años, cuando era joven y pensaba en ser un gran científico, a ese mismo edificio: el DNA, el misterioso y complicado código genético.

Para no hacerle el cuento largo ni aburrirle con los detalles, terminé envuelto en un nuevo proyecto de investigación acerca de la estructura “lógica” del DNA. Resulta que el DNA puede verse como una secuencia de letras (una riesgosa simplificación, pero una simplificación cómoda, por eso suele hacerse), es como un texto en el que están escritas vaya usted a saber qué cosas. Sabemos muy poco de cómo se escribe el código genético, de lo poco que sabemos es que hay unos pedacitos, unas “frases”, que dicen cual es la secuencia de aminoácidos en una proteína, otras de estas frases parecen decir dónde o cuando iniciar la lectura de codificación de las proteínas, sin embargo, la mayor parte de ese texto nos es absolutamente incomprensible.

Piense usted en un libro en ruso, con algunas imágenes de cuando en cuando y sus respectivos pies de figura, imagine que usted no sabe ruso ni tiene idea de cómo se lee el alfabeto cirílico. Ahora póngase a leer el libro… Si sus conocimientos de lingüística son como los míos de ebanistería, lo más seguro es que sólo llegará a saber que cierta secuencia de dibujitos representa alguna imagen, incluso se dará cuenta de que antes de estas secuencias, existe siempre otra con pequeñas variantes que podrían ser las expresiones “figura 5” o “figura 24”. Pues no es mucho más lo que sabemos del DNA. Años de dar palos de ciego nos han permitido hacer pequeños avances, sin embargo, la mayoría siguen siendo elucubraciones basadas en estadísticas poco confiables. El problema con el DNA, a diferencia del ruso, es que no nos es posible ir a buscar a un DNA-parlante que nos explique el “lenguaje”, o peor aún, sí tenemos a los DNA-parlantes, son todos los seres vivos, pero ellos no saben explicarnos qué es lo que hacen para leer ese texto.

Una de los derroteros más grandes de la ciencia, junto a la piedra filosofal, es la manipulación o incluso creación de los seres vivos. No se trata de jugar a Dios o de hacerle un golpe de estado, en esto de la ciencia a Dios no se le ha perdido nada; sino de controlar los sistemas más eficientes que conocemos. Los seres vivos son adaptables, se reproducen solos (casi siempre), pueden transformar un montón de cosas en otro montón de otras cosas. Imagine usted bacterias que sinteticen combustibles orgánicos como el petróleo, o plantas como el frijol de las que podamos obtener fibras como el papel y el algodón. Modificar y crear seres vivos ha sido y será siempre una de los causales más importantes de la ciencia.

Parte de ese derrotero incluye, por supuesto, poder escribir DNA, pero para poderlo escribir, hay que aprender a leer, y eso es lo que aún no sabemos hacer. Podemos hacer Copy-Paste, que es lo que hacemos con los transgénicos, pero no podemos aventarnos ni un párrafo a capela. La búsqueda de la estructura “lingüística” del DNA ha ocupado ya a muchos investigadores, algunos lo han intentado incluso con las gramáticas generativas de Chomsky, pero no le hemos podido dar al clavo.

Alguien decía que la mejor manera de salir bien librado de este mundo es buscar obras gigantes, obras tan grandes que nadie las pueda realizar, lanzarse entonces con actitud de héroe a la aventura y morir en el intento. En nuestro lecho de muerte, nadie nos podrá reclamar que no lográramos terminar lo que empezamos, nadie hubiese podido. Confieso que me siento un poco así; siento que me estoy embarcando en una de esas tareas irrealizables. Si nadie ha logrado encontrarle pies y cabeza ¿cómo es que cuatro gatos podrán ahora encontrar el inicio de la madeja? Si no fuese porque en el intento tendré que hacer muchas otras pequeñas tareas bastante más modestas, bastante más realistas, importantes aunque no tan espectaculares, no habría aceptado la propuesta.

Pero piénselo, querido lector, si le dijeran que va a poder participar en un proyecto ambicioso, tan ambicioso que quizá nadie lo termine, en donde podrá aplicar algunas de las técnicas más modernas de computación y generación de software, conocimientos y tecnología lingüística, matemáticas, comunicación, y todo eso, para adentrarse en la obscura selva de la biología y de la vida, ¿no aceptaría usted sin pensárselo una vez? ¿no diría que sí con una sonrisa de oreja a oreja?

Algún día podremos leer ese libro en ruso, algún día podremos manipular a voluntad a los seres vivos, ese día cometeremos nuevos errores, pero quizá también viviremos mejor, no lo sé, pero vale la pena pagar por ver, y vale la pena incluso intentar participar en ese loco maratón.

Van a decir que yo soy un contreras masoquista, se equivocan, aunque la explicación sería muy larga para este post, dejémoslo en que a veces, como ahora, disfruto de leer aquello con lo que no estoy de acuerdo. Resulta que nuevamente Luciano Cassisi ha escrito en Foro Alfa y nuevamente tengo algo que decir de lo que dice, y como en el Foro ese no hay coso para mandar comentarios y mi comentario va pa’largo, prefiero ponerlo aquí, aunque casi nadie lo lea.

El rollo de Cassisi ahora es sobre la definición del diseño, y es que Luciano parece no sentirse cómodo con las ambigüedades y las incertezas del lenguaje. Lo que no sé cómo hace, es para apañárselas con las siempre deficientes definiciones de diccionarios.

Mi objeción con Cassisi no es por sus argumentos, sino con su intención. A mi eso de definir cosas me pone nervioso. Definir suele ser uno de los actos más ingenuos de la razón humana. Se supone que las definiciones deben ser completas y exhaustivas, es decir, que todo lo que deba incluirse, se incluya, y lo que no tenga que ver, quede fuera, pero ya desde aquí el lenguaje se nos pone difícil y rejego: qué es eso de no tener que ver, o de quedar fuera, fuera de dónde.

Desde hace muchos años, existen dos formas muy distintas de pensar, los normativos, los que parecen creer que normando, definiendo y excluyendo pueden controlar una teoría, una actividad o una sociedad; y los desordenados que nos importa poco la ilusión de la objetividad y la desambigüedad, los que traspapelamos ideas. Tengo la impresión de que Luciano es de los primeros y la seguridad de que yo soy de los segundos.

No sé si usted recuerde aquel libro de Susan Sontag: “Contra la interpretación” en el que habla de la dificultad, pero sobre todo, de la inutilidad de definir lo que es el arte y lo ingenuo que es el deseo de entenderlo. Pero más claro que Sontag fue Xenakis, si no mal recuerdo, cuando le preguntaron que qué era la música:

Mire, si una mujer se pone a hacer ruido con los trastos de su cocina, eso no es música, pero si llego yo y lo grabo y luego lo reproduzco en una sala de conciertos, eso es música.

Una de las ideas detrás de esta genial explicación es que la música es la intención de que sea música. Lo mismo pasa con el arte. Es arte lo que los críticos y otros artistas dicen que es arte. Si en nuestra época el performance y el happening son arte, pues nos amolamos los que no vemos ni pies ni cabeza en muchas de esas expresiones, arte dijeron que es y arte se quedan.

Con el diseño gráfico, me temo que las cosas van igual, más de lo mismo pues, y es que será diseño gráfico lo que la comunidad de diseñadores, publicistas y gente con vela para esa misa digan que es diseño gráfico. Ayer el grafiti era un insulto y una contaminación visual de las ciudades, ahora es diseño y arte, mañana vaya usted a saber.

La realidad es, al final, una construcción lingüística y esto es aún más claro con los conceptos abstractos como “diseño gráfico”, “arte”, “ciencia” y muchos más. Las cosas son lo que decimos que son, o lo que dicen ciertos grupos de influencia.

En este sentido, lo que dice Cassisi no es cualquier cosa, él pertenece a este grupo de individuos que pueden decir qué es y qué no es diseño gráfico, y no me refiero a sus definiciones, sino a sus juicios sobre el trabajo de otros. Para Luciano, lo que un ilusionado oficinista haga en su Power Point no es diseño, y lo mismo opinan un montón mas de diseñadores (que son considerados así, a su vez, por otros diseñadores…), por lo tanto, la presentación que el emocionado personaje termine realizando, no será diseño hoy, pero puede que se le conceda el ascenso si un día los diseñadores deciden dejar entrar estos ejercicios casuales a su élite conceptual.

En fin, que vale la pena leer a Luciano, incluso si usted, como yo, no está de acuerdo con él.

Alistair Cockburn, uno de los más importantes teóricos del desarrollo de software y sin duda uno de los más exitosos como desarrollador discute en su Wiki acerca de la diferencia entres dos tipos de libertad que son incompatibles e irreconciliables.

La libertad de hacer y la libertad de no ser disturbado. La primera corresponde al concepto más típico y fácil de libertad, le llamamos libertad de expresión, libertad de tránsito, libertad de decisión, etc. La segunda es un poco más interesante, y es que no todos consideramos ésta última como una forma más de libertad. Se trata de la libertad o el derecho a no ser afectado por las acciones de los demás. Quizá la confusión viene del lenguaje y su posibilidad para formular frases como “libre de interferencia” o “libre de polvo” que sin duda es una forma común, tanto en inglés como en español, del uso del adverbio “libre”.

En primer lugar, no creo que libre y libertad puedan entenderse como “sinónimos”, y es que aunque podamos hablar de “estar libre de ataduras” como una forma de libertad, no podemos hacer lo mismo con cualquier uso lingüístico, por ejemplo, si decimos que algo está “libre de manchas” no podemos encontrar una “libertad” que represente el concepto de “limpio” que es el que más bien estamos expresando. En este caso, “libre” quiere decir más bien “en ausencia de”, y me es difícil entender la libertad como una ausencia de algo particular.

Me parece muy importante lo que apunta Cockburn respecto a que las leyes que representan nuestras “garantías” se refieren a la libertad de hacer, y las leyes que rigen nuestras “obligaciones” responden a garantizar que las personas no afecten a las demás, es decir, a garantizar el ser “libre de disturbios” tanto a los individuos como a la sociedad. Las obligaciones son traducidas rápidamente en prohibiciones, en restricciones de la conducta expresable por los individuos.

Lo curioso del asunto no es saber cuál es el equilibrio ideal entre ambas formas de libertad, sino que las diferencias sociales están vinculadas a estos equilibrios. En los ejemplos de Cockburn, vemos que las sociedades donde la balanza se inclina a favor de la libertad de no disturbio como podría ser Suiza, la gente tiende a interaccionar menos entre sí; la interacción social se convierte en una forma de disturbio, y es el estado el que debe intervenir como mediador, juez e interventor en estas cuestiones, por ejemplo, si usted tiene un árbol a la entrada de su casa, colindante con la casa de su vecino, y crece una rama que traspasa la propiedad de aquel, a pesar incluso de que se saluden cordialmente todos los días, su vecino no le dirá nada a usted, hablará a la policía y les explicará el problema, ellos le tocaran a usted y le pedirán que recorte el árbol, usted no se ofenderá porque así se hacen las cosas por allá y cortará el árbol. Al día siguiente, usted y su vecino se saludarán cordialmente como siempre.

En gringolandia las cosas no son como en Suiza, las leyes que protegen al individuo de no ser disturbado no son tantas ni tan complejas, por lo que los individuos tienen que resolver muchos conflictos mediante la mediación directa, tratando personalmente unos con otros. En México las cosas son aún más extremas, aquí las leyes de “no disturbio” son menos que las gringas, pero además, el cumplimiento de la ley y la eficiencia de la policía dejan mucho que desear, por lo que los mexicanos nos vemos obligados a mediar y negociar constantemente sin la intervención del estado.

Para mi, al igual que para Cockburn, es más deseable un lugar donde la comunicación y la auto-organización son favorecidas que uno en el que el estado interfiere en casi todas las interacciones sociales. Prefiero tener que pelearme con mi vecina porque ella insiste que la calle frente a su casa le pertenece y yo le digo que la calle es de todos a que para resolver el más mínimo conflicto tengamos que hablarle a la policía. Y es que es muy fácil pasar de garantizar el no disturbio a la represión, como es el caso de las leyes discriminatorias hacia los fumadores.

Por un lado, en sociedades como la mexicana tenemos el problema de un continuo estira y afloja entre las personas para resolver nuestros problemas sin la intervención del estado, al grado de que algunos se la toman muy en serio y se agarran a trancazos, pero también tenemos muchas garantías acerca de nuestra libertad de hacer, en este país podemos decir que el presidente es un idiota, que hay que matarlo, y nadie nos puede hacer nada. Para los gringos las cosas no son así, recordará usted el caso de la escuincla que escribió en su blog que había que matar a Bush, lo que ocasionó que le callera un escuadrón de agentes SWAT en el recreo y la arrestaran por “terrorista”. Otro ejemplo lo tenemos en España, en donde existe eso de la “apología del terrorismo”, que permite al estado enjaular a quien ande diciendo que la ETA es buena o que no son terroristas.

Lo que me queda claro es que si garantizamos una libertad de hacer, estamos restringiendo una libertad de no disturbio y viceversa, y que el grado de comunicación e interacción social está muy relacionado con el tipo de leyes que tiene una sociedad. Lo que ya no es claro es qué distribución en la balanza es mejor, sólo podemos decir cual nos gusta más, en cual nos sentimos más cómodos. Yo personalmente, prefiero más libertad de hacer, pero bueno, yo no soy ni gringo ni suizo ni soy usted.