La agilidad se enferma de certifiquitis

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”?

Las antienseñanzas de Christopher Alexander

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.

Excel para sortear a los desarrolladores

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.

¿Versionamiento para todo?

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.

La herejía de Kent Beck

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).