Tres libros fundamentales sobre Test Driven Development

TDD es una de las prácticas ágiles que más interés generan. En este post presentamos tres libros fundamentales sobre el tema, cada uno apuntando a un aspecto distinto de la técnica. Test-Driven Development By Example - Kent Beck

Este es el primer (y el mejor) libro sobre la mecánica de TDD. Kent Beck nos presenta los principios básicos de la práctica y luego los ilustra mediante el desarrollo de dos proyectos reales: una biblioteca Java para manejar dinero con monedas heterogenas y un port de xUnit a Python.

Lo más interesante de este libro es ver a un gran programador como Beck en acción, lo que nos permite aprender sus técnicas y ver hasta que extremo lleva TDD. Es especialmente educativo ver como combate la duplicación de código.

Además el libro contiene una serie muy útil de patterns de TDD y Refactoring.

xUnit Test Patterns - Gerard Meszaros

Cuando los que escribimos este blog empezamos a hacer TDD (hace ya más de 5 años!), pensábamos que la calidad del código de los tests no era tan importante como la del código de producción. Muy pronto aprendimos que esto era un error y que descuidar el código de los tests nos llevaba a que costara más el mantenimiento de los tests que el del código de producción.

Este libro es una colección de patterns que permiten escribir tests más rápidos,más mantenibles, más claros y más sólidos. También contiene una serie de smells, es decir de síntomas que nos permiten detectar problemas en nuestros tests aun antes de que estos problemas se hagan evidentes. Si están por introducir tests de unidad en un proyecto, sería una gran idea leer este libro antes.

Working Effectively with Legacy Code - Michael C. Feathers

Cuando hacemos presentaciones sobre TDD, una de las dudas que más frecuentemente surgen es ¿Cómo puedo usar esto cuando tengo mucho código desarrollado? Este libro es la respuesta. Michael Feathers presenta patterns, técnicas y herramientas para introducir gradualmente tests de unidad en aplicaciones que no los tengan.

Es interesante su definición de aplicacion legacy: una aplicación sin tests de unidad. Es decir que si uno está desarrollando una aplicación nueva sin tests, está generando una aplicación legacy aun antes de pasar a producción!

Flexibilidad ante el cambio

Inmaginense la siguiente situación: Comienzo de un proyecto, el Gran-Gerente de proyecto, Gran-Jefe-Saco-Agua-De-Las-Piedras reune a todo el equipo y anuncia "El equipo de funcionales va a comenzar con la (Gran)Etapa de relevamiento, durará unos 10 meses. Queremos lograr entender completamente lo que quiere el usuario asi no vamos a tener ningún cambio y vamos a saber todo para cuando entremos en la etapa de desarrollo, que durará unos 3 meses.". Esta es una situacion real, números de meses incluidos. Me sucedió a mi.

Una y otra vez todos hemos estado en proyectos adonde pasa mas o menos lo mismo: Una Gran Etapa De Relevamiento al principio del mismo para "evitar" tener que realizar Cambios y para aprender TODO lo que hay que aprender. Una y otra vez hemos llegado a la mitad o al final del proyecto, con varios meses de retraso respecto de la fecha original, cuando, al mostrarsele el sistema a los usuarios comienzan a aparecer estos "cambios-que-se-suponian-que-no-tenian-que-existir".

Porqué pasa esto? Son los usuarios una fraternidad de sádicos a los que les gusta torturarnos? Son los funcionales, los desarrolladores personas altamente perturbadas y disfuncionales (eh... mejor no contestemos esto) que no pueden entender lo que el usuario les pide? Existe el destino y se empeña en ponernos piedras en el camino?

O será que el cambio es una parte normal de todo proyecto?

Hasta el surgimiento de las metodologías ágiles el cambio se trataba (se sigue tratando) como una anomalía, como un error del usuario o como un síntoma de que alguien se equivocó y no relevó lo suficiente. Cuando hablamos de cambio lo hacemos en todo sentido pero particularmente de los requerimientos y necesidades del usuario.

Por este motivo es que Waterfall indica que debe realizarse una Gran Etapa de Relevamiento al Principio (en inglés, BRUF, Big Requirements Up Front), seguido de escritura de casos de uso (indicado por el DR. RUP) y terminando con requerimientos firmados por usuarios temerosos (de meterse en camisas de once varas y de estar firmando los "10 mandamientos del sistema" tallados en Mármol!).

PMI lo trata con un proceso de "gestión de cambio" o "Control de Cambio" adonde en base a un pedido de cambio del relevamiento inicial se realiza un "cambio de alcance", lo cual implica reestimar costos, chequear asignación de recursos, reestimar tiempos, replanificar y obtener la autorización del sponsor / Gerentes del proyecto para proceder con el cambio. Cualquier parecido con la tortuga de Mafalda es pura coincidencia (La tortuga se llamaba Burocracia).

Justamente uno de los principios comúnes a todas las metodologías ágiles es: El cambio es parte de la realidad!

No es un hecho excepcional, no es causado por usuarios viles y sádicos que quieren hacer un infierno de nuestras vida. No es causado por analistas funcionales perezosos (bah, vagos) o que no saben como escribir un caso de uso (que los hay, los hay) ni por malos programadores que malinterpretan lo que esta escrito en la lista de requerimientos (de estos también hay). Sencillamente es que no importa cuanto tiempo le dediquemos al relevamiento, no importa cuantas Maquetas, prototipos o casos de uso hagamos para mostrarle al usuario, no importa cuanto esfuerzo le dediquemos a reuniones de validación, siempre siempre siempre va a haber cambios a partir del relevamiento inicial (por favor, vuelvan atras y lean de nuevo esta frase).

Porqué? bueno, los principales motivos son :

1. El usuario ve el sistema funcionando y ahí se da cuenta lo que realmente quería .
2. El usuario descubrió a lo largo de todo el tiempo de trabajo en conjunto con analistas y desarrolladores lo que necesita.
3. Funcionales y Programadores aprendieron del dominio del problema y son capaces finalmente de entender lo que el negocio necesita ahora que el usuario finalmente aprendió.
4. El negocio simple y sencillamente cambió.
5. La legislación cambió.
6. El/Los usuarios cambiaron (y usuarios distintos quieren soluciones distintas).

Es decir, simple y sencillamente porque es NORMAL que la realidad cambie (un cambio en alguna regulación, etc, el mercado cambia, aparece un nuevo producto, etc). Y es NORMAL que el conocimiento cambie a medida que uno va teniendo más información y aprendiendo. Esta información solo se puede obtener a través de la experiencia. Esto es así porque al ser un sistema un modelo abstracto de la realidad el usuario sólo se da cuenta de las consecuencias de lo que pidió cuando lo ve funcionando, cuando lo "toca".

Que mente perversa nos metió en la cabeza la idea de que podemos preveer de entrada la forma en que se va a comportar la realidad!? Que cambios se van a producir en el mercado? que leyes saldrán? que va a querer el nuevo usuario o de que se va a dar cuenta el usuario que tenemos cuando le mostremos el comportamiento de las reglas de negocio que relevamos en casos concretos? seria como predecir el clima, pero de aca a un año!.

Una simple muestra para ver el lugar que ocupa el cambio en las metodologías ágiles, en el primer libro de XP, llamado "XP Explained", de Kent Beck, tenia como subtitulo "Embrace Change", abracemos el cambio!

Escuchemos de nuevo finalmente a Kent Beck, en un fragmento de su libro "Implementations Patterns" :

"Nuestra industria parece adicta a la idea de que solo si diseñamos el software bien de entrada no tendremos que cambiar luego el sistema.

Recientemente lei una lista de razones por las que el software cambia. En la lista estaban los programadores que no hacen bien su trabajo al entender los requerimientos, sponsors y usuarios que cambian de parecer y otros motivos mas. El unico factor que faltaba en la lista era justamente el cambio legítimo. La lista asumía que el cambio es siempre un error.

¿Porque no sirve un pronostico del tiempo para todos los dias? Porque el tiempo cambia de manera impredecible. ¿Porque no podemos listar de una sola vez todas las formas en las que necesitaremos que el sistema sea flexible? Porque los requerimientos y la tecnología cambian de manera impredecible.

Esto no nos releva de nuestra responsabilidad de hacer lo mejor que podamos para desarrollar el sistema que el usuario necesita ahora pero sugiere que hay límites al valor de hacer sistemas a prueba-de-cambios-futuros, a través de la especulación.

Poniendo todos estos factores juntos, la necesidad para que el sistema sea flexible ante el cambio, el costo de esa flexibilidad, la impredecibilidad de adonde será necesaria, me lleva a creer que el momento para introducir esa flexibilidad es sólo cuando la misma es absolutamente necesaria".

Estás realmente haciendo desarrollo ágil?(Traducido con permiso de Jake Scruggs)

Hace tiempo que los que escribimos este post venimos viendo como ha ido quedando de lado y, casi diría, en el olvido la metodología de desarrollo Extreme Programming, conocida como XP, que no trata solamente de prácticas de programación, una creencia bastante extendida. Lo que sigue es la traducción de un post interesante que escribió recientemente Jake Scruggs, Are you really doing agile development?, y que aquí publicamos con su permiso.

Recientemente en el trabajo me pidieron que ayudara a hacer a la compañia más "ágil". Bueno, como primero soy un desarrollador y segundo, un fanático estudioso de procesos, respondí con mi usual "Cuantas, de las 12 prácticas están realmente siguiendo?". Mi pregunta fue recibida con muchos ojos grandes y bocas abiertas. Parece que las 12 prácticas de XP clásicas no son fáciles de ubicar estos días en internet. Tambien parece que la palabra "ágil" (de las metodologías ágiles) ha sido tan exitosa en su difusión que muy poca gente parece recordar que XP significa Extreme Programming. Ahora bien, soy el primero en admitir que "Extreme Programming" es un nombre colosalmente estúpido, pero lo que me gusta de XP y sus 12 prácticas originales es que fueron controversiales y fáciles de evaluar: O bien las estabas siguiendo o no lo hacias.

Lo que no me gusta de la palabra "ágil" es que es tan amplia y definida de una manera tan difusa que casi cualquiera puede autoengañarse y creer que ya es completamente ágil.

Asi que, para solucionar esto, y ayudar a mi compañia a comenzar a medir mejor su "agilidad" , decidi listar las 12 prácticas de XP clásicas (A través del tiempo cambiaron...pero no para mi. Y mantenganse afuera de mi jardin!) y mi altamente subjetiva opinión sobre cada una de ellas. Al final les diré como calcular su índice de "agilidad".

* Planning Game o juego de planificación Obtener requirimientos del usuario, armar historias de usuario (cortas), estimar el tiempo que llevará hacerlas, hacerlas, medir velocidad, examinar estimaciones erradas para pistas acerca de como estimar mejor y repetir. Una historia es una promesa de conversación -- esto solo funciona si el usuario (o representante) está altamente disponible para los desarrolladores y los desarrolladores aprovechan esa disponibilidad chequeando constantemente dudas y presunciones durante el proceso de desarrollo. Nota: Historias que toman más de un dia para completarse reducen el éxito de otras prácticas de XP.

* Small Releases o versiones pequeñas LAs iteraciones deben ser de 1 o 2 semanas (dependiendo de cuan doloroso/caro sea organizar una iteración). Despues de cada iteración se debe implementar una versión en productivo si la aplicación es fácil de desplegar (como por ejemplo una aplicación web).

* Metaphor - Metáfora Nadie sigue esta práctica, puntos extras si tu lo haces.

* Simple Design - Diseño Simple Esto significa distintas cosas en distintos niveles. Cuando se esta empezando un proyecto desde cero, una semana de relevamiento de requerimientos y diseño esta bien. Para una historia individual, diseñar desde unos minutos hasta una hora está bien. Después uno comienza a programar. Importante: Se diseña a medida que uno desarrolla. Para para pasar unas horas en frente de un pizarrón está permitido, e incluso, alentado. Hacer la cosa más simple que pueda funcionar hasta que se vuelva obvio que no funciona. Entonces se rediseña. La idea es que el comienzo de un proyecto es el momento que uno sabe menos del mismo-- por eso hay que distribuir el esfuerzo de diseño a lo largo de la vida del proyecto de manera de poder tomar decisiones cuando uno tiene más conocimiento.

* Testing Testear antes de programar. Cubrimiento del 80% para Java, 90% para Ruby (menos chequeo de exepciones en ruby hace más fácil aumentar el porcentaje de código cubierto). Tests Robustos, atómicos, rápidos. (los Test de unidad deben correr en menos de 5 minutos, todos, en realidad es mejor si es menos de un minuto pero la mayoria cree que es imposible (Les adelanto la respuesta: ES posible )

* Refactoring - Refactorización de código En breve: Rojo, verde, refactorizar!, respuesta larga: Escribir un test que falle, hacerlo pasar, refactorizar el código. Tambien significa que cuando estás pasando por un lugar (de código) desordenado lo dejas un poco mejor de lo que lo encontrastes.

* Pair Programming - Programación de a pares

Más del 80% del tiempo. En serio. Tareas en las que parece que no se puede programar de a pares a menudo significan que no estas usando las técnicas de pair programming correctas. Programar de a pares es una habilidad sobre la que se trabajar. Practiquen para ser mejores en ella.

* Collective Code Ownership - Compartición de código colectiva

Cualquiera puede cambiar cualquier parte del código. Si, deben consultar al que conozca más acerca del código a modificar pero no hay ninguna parte del codigo que sólo el desarrollador X puede tocar.

* Continuous Integration - Integración contínua

Cada check-in en el repositorio remoto dispara un set extensivo de tests de unidad. Los programadores deben ocuparse si el build falla. Por ejemplo, cuando el build falla nadie hace más check-ins hasta que se soluciona. También debe haber algúna penalización social para el que rompe el build (Debe usar un sombrero estúpido por el resto del dia, un deshonroso trofeo "Rompedor del build" que se ubique en el escritorio del susodicho, debe comprar donas o algo para todo el equipo, etc.). Todo esto se basa en la presunción de que el build es confiable y que una falla significa un problema real.

* 40-hour Week - Semana de 40 horas

Ahora es llamada "Paso sostenible" porque "semana de 40 horas" tendía a asustar a los gerentes y corridas de final del proyecto son a veces necesarias incluso en XP. Esto no debe durar por más de 2 semanas, tener un punto claro y definido a partir del cual las horas de más se terminan y no debe suceder más de dos veces en el año. En verdad, si sucede dos veces en el año significa que se deben mejorar las habilidades de estimación.

* On-site Customer - Usuario in-situ

No sucede a menudo para proyectos internos. Se usan en general representanes de Usuarios (o proxies). Estos representantes necesitan tomarse el trabajo de hablar con los usuarios reales constantemente (no solo con los gerentes de los usuarios) y estar totalmente disponibles para contestar preguntas y dudas de los programadores.

* Coding Standards - Estandares de desarrollo

No importan cuales sean pero los programadores necesitan llegar a un consenso y mantenerlo. El consenso no significa que todos digan "si" en la reunión y luego ignoren los estandars cuando les conviene.

Asi que, como obtenemos el índice de agilidad? Tomen la cantidad de prácticas que realmente siguen, dividanlo por 12 y multipliquenlo por 100-- este es el porcentaje de ágiles que están haciendo. No se den un punto si no implementan real y completamente la práctica. Tienen integración continua pero algunos de los tests fallan de manera aleatoria? ningún punto. Programan de a pares "cuando es necesario" lo cual termina siendo el 40% del tiempo? ningún punto! Hacen iteraciones pero no estiman las historias? ningún punto!!

Este es un momento para mirarse objetiva y seriamente ante un espejo, no una fiesta de amor hippie, i.e, la Hippie-Love Fest.

Con Scrum no alcanza

Empezando un poco con el tema de metodologías ágiles en general quiero pasar a este blog, de alguna manera repitiendo su publicación, un post que habia escrito respecto a una conversación dentro del marco de la lista sobre metodologías agiles en habla hispana, foro-agiles@yahoogroups.com. De paso la idea es "aggiornalo" o mejor dicho, ponerlo un poco mas en contexto dentro de este blog.

Como ya contamos comenzamos a interesarnos en las metodologías ágiles allá por los años 2002/2003, cuando leímos un par de libros sobre eXtreme Programming (XP), "XP Explained" de Kent Beck y "XP Installed", de Ron Reffries que llegaron en el momento justo, cuando estabamos en crisis, en la búsqueda de ciertas respuestas. LLevabamos en ese momento casi 10 años de trabajo profesional y estabamos seguros de que tenía que haber otras formas, mejores, de encarar el desarrollo de software. Ni Waterfall ni RUP, ni la utilización de una gran etapa de relevamiento con UML habian cambiado en lo mas mínimo la mala situación de la mayoría de los proyectos en los que participabamos. Al final sucedia siempre lo mismo: El grupo de desarrollo, realizando una marcha forzada contra reloj, se esforzaba heroica pero inútilmente en terminar un sistema que al usuario luego no le servía.

En los años siguientes, las metodologías ágiles comenzaron a ser cada vez más populares, y se ensanchó grandemente su audiencia. Esto sucedió básicamente a través de la difusión masiva de Scrum y sus certificaciones, por encima de XP (y su relacionada Industrial-XP ) y Cristal Clear (de Alistair Cockburn) , que han quedado mucho mas relegadas. Creo que en parte ganó la noción que estas otras metodologías, particularmente XP, solo se ocupaban de la programación y no de la gestión y organización del proyecto. Esta idea es totalmente errónea pero es un tema que trataremos en otro momento.

LLendo al titulo del post, aclaramos por si las dudas: Estamos a favor de Scrum. Personalmente creo que es una buena metodología/ framework / conj. de buenas prácticas/ comoseaqueunolodefina, de lo mejor que hay dando vuelta por el ala ágil del arco de desarrollo (es la mas difundida, seguro).
Lo que desafío es la noción de que con Scrum sólo alcanza para obtener excelentes resultados en un proyecto de desarrollo de software. Más bien me juego por lo contrario, con Scrum solo solo (valga la redundancia) alcanza para fracasar. Lo digo en serio. Cuando mucho será un fracaso menor o más rápido que con una metodología tradicional, de las monumentales, con más participación del usuario, pero fracaso al fin.

A ver, en teoría es suficiente con hacer muchos Sprints, muchas retrospectivas, cierta transpiración y luego de un cierto numero de iteraciones....voila! van a ir surgiendo en el grupo un conjunto de buenas práacticas de desarrollo, se van a ir corrigiendo errores, eliminando impedimentos y llegaremos a tener un proceso aceitado que permite conseguir un producto de alta calidad deleitando a nuestros usuarios, verdad?

FALSO (IMHO) porque:

1. Muchos proyectos no duran tanto para lograr mejorar la calidad del producto a través de retrospectivas y permitir que surjan buenas practicas de desarrollo, en parte por "culpa" del mismo Scrum. El hecho de realizar reviews cada 2 o 3 semanas del Sprint implica una Alta Exposición ante el usuario (claro que estoy a favor del feedback constante), el hecho es que si estamos construyendo...crap, es decir, porquerías vamos a estar mostrando porquerías... y los usuarios suelen tener poca paciencia... (y ni hablar de nuestros "ágiles" gerentes...).


2. Los equipos de desarrollo no suelen estar juntos y evolucionar juntos en distintos proyectos (algo que mejoraría el punto anterior porque no tiene que producirse la evolución en el proyecto presente sino que puede venir de proyectos anteriores) por la altísima rotación producto (bendita sea) del mercado dinámico y de ciertas condiciones de contratación precarias. Es la realidad en que vivimos por lo menos aquí en Argentina, y me atrevería a arriesgar en muchos lugares del mundo incluso a pesar del impacto de la crisis mundial.


3. Un grupo de desarrolladores (Programadores) no aprende de la nada a ser bueno, de la noche a la mañana, no se aprende a realizar buenos Diseños Simples de manera evolutiva e incremental. Lleva mucho tiempo y trabajo aprender a realizar tests de unidad efectivos y mantenibles en variados ambientes tecnológicos y tipos de proyectos. Cuesta y mucho aprender a Programar Orientado a Objetos, pero en serio, de manera profunda no solo aplicando patrones de diseño a diestra y siniestra. Requiere estudio, requiere mucha práctica, mucho esfuerzo y cierta habilidad o capacidad mínima.


4. Cuesta tiempo aprender a coordinar al grupo, Desarrolladores, Testers, Analistas Funcionales, Usuarios, tiempo este que crece exponencialmente con el tamaño del mismo.


5. Nos enfocamos mucho en el proceso.... Planning Meeting - Sprint - Review - Retrospectiva y nos estamos olvidando de la calidad de la gente.... People over Processes , no se si les suena. Y es la gente la que siempre termina dando la solución.


6. Hay un proceso.... dudo en llamarlo... de pauperización o deterioro de calidad de la programación y desarrollo de software que me preocupa, cada vez mas los programadores solo se centran en dominar el siguiente framework X-Y-J, llamese Enterprise Library, WCF, Spring security-MVC-Whatever, Hibernate, Seam, el siguiente "juguete" o arma que les promete la famosa "bala de plata" en lugar de buscar mejorar activamente la calidad del desarrollo y su capacidad de concepción de un desarrollo de más alto nivel, de practicar y adoptar buenas practicas que permitan pensar en algo mas estratégico en lugar de la táctica de corto alcance...


7. Gran parte del mercado de desarrollo se dirige a una complejización cada vez mayor de la tecnología, lo que nos lleva a estructuras de aplicaciones y ambientes cada vez mas complejos e interdependientes.

Todos estos puntos hacen que los problemas de mala gestión, falta de empiriscmo, falta de autogestion y de feedback que vienen a solucionar Scrum sean males "menores" comparados con no empezar a trabajar bien desde un punto de vista técnico desde el primer dia, utilizando buenas prácticas de desarrollo.

En síntesis es poco realista pretender que aplicando Scrum "a la Talibana" y después de unas pocas iteraciones o muchas el grupo vaya evolucionando y mejorando (ojo, que lo hace peroo no) a una velocidad tal que permita desarrollar un producto de muy buena calidad, sin deuda técnica, con alta cobertura de tests de unidad y con un Diseño de objetos solido y extensible, en pocas palabras, un sistema Mantenible (asi con "M" Mayuscula).

Es como pretender realizar un viaje en barco y comenzar el viaje sabiendo que el barco esta lleno de agujeros y se comienzan a tapar en medio del viaje. Lo mas probable es que cuando lleguemos a mitad del camino, en aguas profundas, el barco tenga tanta agua (léase Deuda Técnica) que ,aunque seamos cada vez mejores y mas rápidos en tapar agujeros, el barco (léase Proyecto) se hunda irremediablemente y sin necesidad de chocar contra algún tempano.

Primer Code Retreat Argentina

Este sábado 24/04 organizamos el primer Code Retreat de Argentina, en Buenos Aires. Fue una experiencia muy interesante que nos dejó muy conformes!

El objetivo de este Code Retreat fue familiarizarse con prácticas de Extreme Programming como Pair Programming y Test Driven Development (TDD).

Lo que hicimos fue trabajar en sesiones de 40 minutos, cada una de los cuales consistió en que los participantes intentaran resolver un problema de programación, trabajando de a pares y utilizando TDD. Una vez terminada cada sesión hicimos una retrospectiva de 15 minutos para reflexionar sobre los problemas encontrados y los distintos formas en que cada par había encarado su solución del problema. Después de la retrospectiva se cambiaban los pares, se borraba el código y se iniciaba una nueva sesión atacando el mismo problema.

De esta manera se realizaron 5 iteraciones y por ultimo, una 6ta iteración, en la que realizamos una demostración de un intento de solución del mismo ejercicio del Retreat.

Un punto aparte a destacar es la buena onda y el esfuerzo de todos los concurrentes en participar de un evento un dia no laboral. La integración y la comunicación crecieron en conjunto, iteración tras iteracion.

Los Participantes del primer Code Retreat fueron:
Claudio Meschini
Mario Del Lago
Hernan Vitto
Alejandro Miralles
Fernando Claverino
Gabriel Naiman
Damian Aberbuj
Emanual Teodoro
Amit Stein
Javier Andres Cengia
Matias Nicolas Blanch
Juan andres Knebel
Nicolas Bases
Augusto Bellucci
Claudio Vidau

Tambien agradecemos a Pragma, el Sponsor del evento.

Les dejamos algunas fotos del encuentro y vamos a realizar un post más completo cuando tengamos más feedback de los participantes y escribamos nuestras conclusiones.

El porque de los chimpancés entrenados

Hace un poco más de 15 años, los que escribimos este blog estábamos en la facultad, haciendo nuestras primeras materias de ingenieria de software, después de varios años de materias más técnicas. Fue allí donde por primera vez nos vimos expuestos a la minimizacion de la importancia de la programación, expresada en la siguiente frase:"Si el diseño y el relevamiento de requerimientos es lo suficientemente bueno la programación podría ser hecha por chimpancés entrenados", que figuraba textual en uno de los libros de la materia (Gracias Ed!).

Como no podiamos estar mas en desacuerdo la elegimos como título para nuestro blog.

Esta creencia era y es bastante extendida en el sector y se expresa en metáforas como la de que el desarrollo de software es como hacer "Arquitectura" de un edificio donde una persona especializada se ocupa de realizar un diseño y un grupo de albañiles-programadores se ocupan de la tarea subalterna de transformar es diseño en código.

Además, como la tarea de programación se ve como algo de poco nivel y sencillo, se la ha intentado automatizar varias veces. En la época en que nosotros empezábamos nuestra vida profesional, la herramienta, la bala de plata, que iba a hacer obsoletos a los programadores y a permitir que los funcionales escribieran (perdón, debimos decir: diseñaran) directamente los programas eran los llamados "lenguajes de cuarta generación" o 4GL como Clipper, Clarion o Fox. De todas maneras no fue esta la primera vez que se intentó esto: en los comienzos de Cobol la idea de marketing fue muy parecida. Y hace muy poco tiempo se intentó lo mismo con la idea de UML ejecutable (entre muchos otros ejemplos).

Todo esto chocaba contra la realidad que percibíamos dia a dia, sobre todo porque en nuestra actividad profesional veíamos que la habilidad de los programadores era crucial para el éxito de los proyectos. Hemos visto mas de un proyecto de desarrollo con pésima gestión ser salvado por un equipo de "Heroes-Programadores", que inmolando sus vidas lograban llevar el proyecto al mejor resultado posible. Por el contrario cuando un equipo de desarrollo no era bueno, no importaba ni la mejor gestión ni la metodología usada, sencillamente el proyecto se hundía por el peso de su Deuda Técnica (ya hablaremos de este tema en otros posts).

Por eso, cuando por los años 2002/2003 descubrimos las metodologías ágiles y en especial Extreme Programming sentimos que era algo que se correspondía bastante más a lo que pensábamos y a la realidad en que estábamos inmersos. Nos encontramos con una metodología donde muchas de las prácticas tenían que ver directamente con el código y que además incluía el nombre "Programming" en el titulo.

Pensamos y sostenemos que la programación es fundamental para el desarrollo de software y que si en un proyecto no tenes buenos desarrolladores , que usen buenas prácticas y produzcan codigo de calidad, vas a fracasar independientemente de tu metodología, tus herramientas o la calidad de tu management.

Y esa es la idea de este blog, un blog para los "chimpancés entrenados".