Extreme programming y el desarrollo ágil
A principios de siglo (dicho así parece que queda muy atrás, eh… :P) trabajaba en Indra como coordinador de un equipo de desarrollo. En mi entorno profesional era un poco como un bicho raro porque, además de ser 10 años más joven que la media de mi puesto, era de los pocos que se negaba a abandonar el desarrollo para dedicarme plenamente a la gestión.
Recuerdo que en esa época leí sobre Extreme Programming y me pareció muy interesante. He de reconocer que por aquel entonces no entendí bien la parte de programar en pareja y seguro que malentendí otras partes, pero empaticé con los valores que promovía y algunas prácticas casualmente ya las llevábamos aplicando en nuestro día a día desde los inicios del equipo.
En una ocasión un compañero me vino a buscar y justo estaba leyendo sobre el tema. Sus primeras reacciones al leer las palabras “Extreme Programming” fueron del tipo: “¿programación extrema? ¡aquí no queremos cosas extremas!”. Le comenté que era un proceso ágil que… “ágil, ah! vale, eso ya me gusta más” y el resto de la historia ya da igual.
El freelance y el profesional independiente
El año pasado di una charla en una comunidad de desarrollo y puse en mi bio que era desarrollador freelance. Tengo un conflicto personal con este tipo de “biografías” porque me obligan a definirme y es algo que me suele resultar incómodo, especialmente cuando estoy en un periodo de transición en el que lo que soy no lo termino de tener claro ni yo mismo. El caso es que alguien me comentó: “no pongas freelance, que es una palabra que tiene connotaciones negativas, pon mejor que eres profesional independiente”.
El problema de discutir sobre la palabra
He mencionado estas dos anécdotas precisamente porque para mi son dos ejemplos del mismo problema con 15 años de separación. Cargamos de tanto significado, connotaciones y prejuicios ciertas palabras que al final terminamos adorando u odiando las palabras en si mismas independientemente del significado que tengan para la persona que las utiliza.
Durante el fin de semana vi la charla de David Bonilla sobre “El programador Moderno” y me gustó bastante, aunque no coincidí para nada con él respecto a su interpretación de la metáfora del Software Craftsmanship. Básicamente David interpreta que la escuela craftsman dice que “los programadores de verdad son los que hacen un código que podría pasar cualquier tipo de inspección, que lo que importa es que perfecciones tu práctica de la programación hasta llegar a ser un artesano del software”. El problema es que para mi está haciendo una interpretación que diverge completamente de la que yo hago sobre la metáfora del Software Craftsmanship.
¿Está David equivocado?¿Lo estoy yo? Creo que la equivocación es discutir sobre la metáfora. Estoy seguro de que hay personas que interpretan el movimiento de Software Craftsmanship como lo hace David en su vídeo, otras que lo interpretan como yo muchas otras que lo interpretan de formas completamente distintas.
Lo curioso es que el manifiesto del Software Craftsmanship dice únicamente esto:
Not only working software,but also well-crafted softwareNot only responding to change,but also steadily adding valueNot only individuals and interactions,but also a community of professionalsNot only customer collaboration,but also productive partnerships
¿Quién no puede estar de acuerdo con este manifiesto? ¡Sólo le falta un “making the world a better place”! 😉
El peligro de criticar la palabra en lugar de las prácticas
Desde mi punto de vista, el mayor problema que suele acompañar a la crítica de una metáfora, es que no criticas algo concreto, criticas la interpretación que cada persona tenga de esa palabra. Y el mayor problema es el daño que puedes estar haciendo al colectivo que se identifica con esa metáfora, pero que interpreta la metáfora de una forma distinta a la que tú lo haces.
El ejemplo de David no es el primero ni será el último. En la CAS del 2015, Leo Antoli hace referencia en su keynote a varias metáforas, la del Software Craftsmanship entre ellas. Lo curioso es que en este caso puso una foto de Manolo y Benito, de la serie “Manos a la obra”. No se realmente cuál era el mensaje que quería dar Leo en este caso, pero imagino que si alguien pone en una presentación un slide con su empresa, su nombre, o el de un colectivo con el que se identifica y debajo la imagen de un par de chapuzas, no le haría mucha gracia.
Volviendo al vídeo de David, cualquiera que vea su charla y no tenga idea de qué es eso del Software Craftsmanship, puede que herede el pensamiento de que son un grupo de gente que sólo se preocupan de que su código sea tan limpio que se pueda comer encima. Un poco más adelante David anima al público a que se involucren en la comunidad, asistan a meetups, etc. Supongo pocos asistentes de esa charla se animarán a ir a estos meetups 🙁
Da feedback útil, que no te ciegue la ira 😉
¿Leo o David son malas personas y habría que sacrificarlas ante el dios del Software Craftsmanship? Pues tampoco. Al final son dos personas que han tenido la oportunidad de enviar un mensaje importante y lo han hecho de la mejor manera que han sabido/podido. No me he visto nunca en la tesitura de dar una charla de este tipo, pero imagino que no tiene que ser fácil.
Comunicar no es fácil, muestra de ello es este post, que seguro que me ha quedado un coñazo infumable que no expresa ni la mitad de lo que quería decir. Por eso creo que es muy importante el feedback. Si tienes la oportunidad de dar feedback, no lo dudes, pero desde el respeto. Por ejemplo, a David le respondí a través de Twitter y espero poder continuar la charla un día con unas cervezas. A Leo se lo di en la CAS, justo después de la keynote, y creo que fue un error porque seguro que ni se acuerda de lo que hablamos xD
A todo esto, a mi en realidad la metáfora del Software Craftsmanship tampoco me va, yo soy jardinero del software! 😉