Ultimamente, he leído varios posts quejándose de las metodologías ágiles, como por ejemplo éste. Creo que el problema pasa por que hay gente que no termina de comprender Agile, quizá piense que es algo muy complicado¹, muy extremista. Pero no lo es.

Primero, creo que malinterpreta el significado del precepto #2 del Manifiesto Agil :

“Software funcional antes que documentación extensiva”.

Yo interpreto que la prioridad esta en hacer que el software funcione como tiene que funcionar antes que ponernos a escribir toneladas de documentación. Pero no quiere decir que no escribamos nada de documentación. Para mi no es un falso dilema, no es una disyunción exclusiva.
Es mas bien como lo escribe mas abajo:

“Aceptamos la documentación, pero no cientos de páginas que nadie mantiene y casi nunca se consultan”.

Personalmente, creo que un Wiki, con breves artículos explicando las diferentes partes de una aplicación, más algunos comentarios en el código, es lo ideal.

Luego, el autor del post dice (traduzco):

“Los equipos cambian de integrantes, los proyectos se migran, y la gente se pregunta qué quizo hacer Joe con sus tres mil treinta y tres lineas de código antes de irse de la empresa.”

Acá es donde veo que no comprende bien la filosofia Agile. 3033 líneas de código juntas simplemente no es Agile. Primero porque violaría el principio de testabilidad, seria imposible de testear. Segundo, porque carece de sentido común, sobre lo que se basa todo lo que es Agile. Un método o clase de 3033 líneas no solamente va a ser inentendible para cualquier otra persona, sino para el mismo autor luego de un mes.

Recuerdo que hace varios años, cuando aún no había ni siquiera escuchado hablar de metodologías ágiles, y lo mas común era el modelo en cascada, le comentaba a un amigo: “Es imposible desarrollar buen software de esta manera. Todo cambia demasiado rápido, tiene que haber una manera mejor”.
Obviamente, no fui tan brillante como para inventar una metodología ágil, pero sí lo suficiente como para darme cuenta que se necesitaba algo así, y como para adoptar las prácticas ágiles cuando me enteré que existían.

¹Me recuerda los problemas que mucha gente tenía en la facultad en Análisis Matemático I (yo mismo al principio), para poder entender el concepto de límite. Realmente es algo muy simple, pero a veces lo presentan de una manera que parece algo complicadísimo.

Lately, I’ve been reading a few posts complaining about agile methodologies, such as this one. I think the problem is some people don’t quite understand Agile, maybe they think it’s too complex¹, or too extremist. But it’s not.

First, I think he misunderstands the meaning of Agile Manifesto precept #2:

“Working software over comprehensive documentation“.

My understanding is priority lies in making a functional software under the customer requirements, rather than writing tons of documentation. But that doesn’t means no documentation at all. To me it’s not a false dilemma, is not an exclusive disjunction.

It’s more like he writes later:

“We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.“.

Personally, I think a Wiki, with brief articles explaining different applications parts, plus some comments in the code, would do.

Then, the author says:

“Teams will change staff and projects will migrate and people will be left wondering just what Joe meant and just where he was going with his three thousand and thirty three lines of code before he left the company and the department he worked in was disbanded.”

Here, I can see he doesn’t understand Agile very well. 3033 continous lines of code is not agile. First, because it violates the testability principle, it would be impossible to test. Then, it lacks any common sense, which is the foundation of Agile. A 3033 lines method or class no only will be incomprehensible for any other person, but also for the very author if he/she comes back to the code a month later.

I remember something I told a friend many years ago, when I didn’t even hear about agile methodologies yet, and the most common model was the waterfall model: “It is not possible to write good software this way. Everything changes too fast, there should be a better way“.
Obviously, I wasn’t bright enough to invent agile methodologies by myself, but bright enough to realize that something like that was needed, and to embrace Agile when I learned about it.

¹It reminds me of the trouble a lot of people had in university Calculus 101 (myself at first) to understand the concept of limit. It’s actually very very simple, but sometimes it’s presented in a way that it seems very hard.