Maven. Te quiero. Te odio

Querida... amada Maven:

Ya sabes que nuestra relación ha sido siempre muy complicada. Hemos tenido que pasar por mil y una dificultades, hemos tenido que sortear cientos de obstáculos y aunque siempre parecía que lo nuestro no funcionaba, una y otra vez conseguíamos encontrar esa solución mágica que nos hacía superarlo.

En cuanto te conocí me di cuenta al instante de que recogías muchas de las virtudes que llevaba tanto tiempo buscando. Me volvía loco tu repositorio y tu gestión de las dependencias, con ese toque de transitividad que sabías darle, como nadie había sabido hacer hasta ese momento. Y eso a pesar de que la inseguridad que conlleva la primera vez te llevaba a menudo a no dejar claras tus prioridades. Pasaron años hasta que fuiste capaz de organizarte para que no quedara nunca la duda sobre qué versión elegir. Sólo esto ya era suficiente para estar contigo. Todavía hoy no he visto nunca otra que te haga sombra en esto, como mucho algunas lo que hacen es copiarte sin siquiera querer ocultarlo. No sólo eso, desde el principio me aportaste algo más que necesitaba mucho en ese momento, como es la posibilidad de orquestar varios proyectos y tener una gestión clara de la creación y gestión de sus versiones. Y también facilitabas e integrabas muy bien la ejecución de las pruebas unitarias.

No todo fue bonito, ni mucho menos. Siempre te gustó jugar conmigo, siempre te gustó ponérmelo difícil. Cada vez que se me ocurría proponer algún plan que se saliera de a lo que estabas acostumbrada en cuanto a la construcción de los paquetes y componentes, tú te ponías nerviosa y colocabas barreras para que conseguirlo fuera un suplicio. Algo que parecía muy sencillo se convertía en complicado, y a menudo tenía que buscar cómo engañarte para que te acabara gustando lo que te proponía.

A esto contribuía mucho la falta de comunicación que teníamos. Nunca me decías cómo te sentías realmente, te ponías misteriosa y no me ayudabas a sacar las cosas adelante. Muchas veces me contabas verdades a medias sobre tus plugins, o me dabas información anticuada que había cambiado lo suficiente como para que ya no me valiera, y a menudo tenía que explorar en lo más profundo de tu ser, llegando hasta el mismísimo código fuente, para descubrir lo que te ocurría realmente.

Parte de la culpa de todo esto la tiene seguramente mi ex-novia, Ant, que no tenía ninguna de tus mejores virtudes pero que si brillaba en algo era precisamente en la construcción personalizada de los componentes. Tú siempre has valorado más la construcción estandarizada, y no te lo reprocho, pero no creo que lo uno tenga por qué interferir con lo otro. De hecho mi ex, corroida por la envidia, te intentó copiar y se compró un coche llamado Ivy para competir contigo en la parte más básica, la gestión de dependencias. Mi ex tiene su público, claro, pero cuanto más tiempo ha pasado más me he dado cuenta de lo anticuada que es en realidad. Ahora veo que estandarizar la construcción tiene bastantes ventajas.

En cualquier caso, seguramente lo peor por lo que he tenido que pasar en nuestra relación es que te integrabas muy mal con mis amigos del club Eclipse. No te querías ni acercar por allí, y me obligabas a hacer malabarismos para que no chocarais en vuestros planes. A veces coincidíais tangencialmente y teníais algún tipo de contacto, lo suficiente para aprovechar sobre todo tus maravillosas dependencias, pero el contacto nunca llegaba a ser realmente amistoso.

Con el tiempo mi paciencia fue dando frutos, y gracias a eso te fui descubriendo nuevas sorpresas. Ese repositorio Nexus que mejoraba el rendimiento y hacía de repositorio central corporativo, esos arquetipos que hacían que no tuviéramos que empezar siempre desde el principio, esa integración con herramientas como OneJar y Launch4j que comentaba en mi artículo de hace varias semanas... y sobre todo fue un gran descubrimiento el día que se unió a nosotros nuestro fiel perro, Jenkins. Gracias a él muchas de tus incomodidades se gestionaban mejor, y perdía mucho menos tiempo con todos esos deploys que tenía que hacer tan a menudo. Debo decir que él y tú sí que encajabais perfectamente y parecíais hechos el uno para el otro.

Pero... no quiero salirme del tema. Te escribo esta carta porque me siento engañado.

La otra noche pasé por el nuevo local del club Eclipse en la calle Juno. La verdad es que llevaba mucho tiempo sin conocer ninguno de los locales que habían ido abriendo por la ciudad, quizá con miedo de que tu falta de integración se acrecentara en ellos.

Y cual fue mi sorpresa cuando... te vi allí, en el club. Alternando con todos, como una ramera barata. Dejando que cualquiera te tocara el culo sin poner ningún tipo de oposición. Hablando con todos, ayudando a todos. Con todos, hasta con el más tonto de los dummies. Cualquiera era capaz de manejarte, de entenderte, así de fáciles les ponías las cosas. De repente, dejaste de lado todas esas dificultades que me habías puesto a mi. Hacías que usarte fuera lo más fácil del mundo, que prácticamente no hiciera falta saber nada. Que con dos clicks tuvieras creado tu proyecto y que con otro más añadieras las dependencias que necesitaras. Por supuesto, sé que debes seguir teniendo complejidades escondidas, que irían apareciendo con el tiempo. Pero llegar a ti es ahora mucho más fácil.

Sé que no te diste cuenta, que me confundiste con cualquier otro de los múltiples acompañantes que tuviste, pero esa noche... esa noche yo también te usé. No pude evitarlo. Ya no soy importante para ti... debería matarte, o al menos abandonarte para no volver a verte jamás. Los celos me carcomen, no puedo soportarlos. Pero ya no puedo vivir sin ti. Es mucho lo que me das.

A partir de ahora seré uno más en tu vida, otro usuario anónimo que entra y sale pasando desapercibido. Pero quiero que sepas que nuestra historia fue muy especial durante mucho tiempo y que no te olvidaré jamás. No es una carta de despedida, pero sí que es la última vez que te hablaré como alguien especial y cercano a ti.

Te quiero. Te odio.


P.D.: Tengo una nueva vecinita llamada Gradle que me está intentando seducir. Sabe qué teclas tocar, ya que afirma que reúne tus ventajas con las de mi ex. Por ahora me resisto, he sufrido demasiado y no me siento con fuerzas para empezar otra vez, pero como un día me dé por conocerla mejor igual te acabas olvidando de mi para siempre...

Metodologías ágiles. ¿Me las creo o no me las creo?

Últimamente parece que los congresos y otros saraos sobre metodologías ágiles de desarrollo aparecen de debajo de las piedras. Están de moda, está claro. Ante todo, debo reconocer que aunque realmente me encantaría haber podido hacerlo, hasta ahora no he participado nunca en un proyecto en el que se siga alguna metodología ágil. Así que en este artículo parto del desconocimiento y diré irremediablemente un montón de tonterías. En cualquier caso, ya adelanto que las metodologías ágiles me generan tanto entusiasmo como dudas.

En el año 2001, Kent Beck (que básicamente quería vender su libro) convocó a unas cuantas mentes pensantes del desarrollo software y, con una cerveza en la mano, les dijo algo así como: "Señores, ¿están tan hartos como yo de tanta tontería?". El resto se miraron unos a otros, pensando cada uno en ese sufrimiento que les acarreaba el día a día en el trabajo: la incomprensión de sus jefes, ese documento que no vale para nada y nunca se acaba, el echarse las culpas unos a otros... Así que cogieron la petaca de whisky, la apuraron de un trago y todos al unísono gritaron: "¡¡¡Cambiemos el mundo!!!". Vale, seguramente no fue exactamente de esta forma, pero ey, si yo fuera a hacer una película sobre el tema la haría así, ¿qué pasa?.

El caso es que dice la leyenda que estos 17 tipos se pusieron de acuerdo para redactar los 4 principios maestros del desarrollo ágil, recogidos en lo que vinieron a llamar el manifiesto ágil (por cierto, cualquiera que haya estado en una reunión de su comunidad de vecinos sabrá que el que 17 tipos se pongan de acuerdo en algo en una tarde es cuanto menos difícil de creer, pero atribuyamos el mérito al alcohol y créamoslo, que al fin y al cabo da un poco igual si sucedió así o no). Los 4 principios tienen la forma "X mola más que Y", que no es que Y no mole, que si hay que ir se va, pero es que X es la leche y es lo que hay que potenciar. Estos son los 4 principios o valores.

1. Viva la gente (la hay donde quiera que vas)

Como comentaba en mi primer artículo sobre UML, unos años atrás las mentes pensantes del desarrollo de software se estrujaban las meninges buscando una metodología que hiciera el desarrollo tan fácil que cualquier mequetrefe fuera capaz de hacerlo con los ojos cerrados. Se pretendía que el desarrollo no fuera un proceso creativo, sino que siguiendo unos pasos bien definidos se pudiera casi automatizar.

Pero esto no es cierto. Lo cierto es que para hacer un buen diseño, que sea flexible y mantenible, tienes que ser creativo. Tienes que pensar. Y está demostrado que un buen desarrollador cunde más a largo plazo que muchos malos.

Por otra parte, también está demostrado que el rendimiento de una persona que está motivada con lo que hace es infinitamente superior al de la que no lo está. Esto tiene muchas implicaciones. No es fácil estar motivado. Tienes que sentir que controlas completamente el software que estás haciendo, que lo conoces bien, que tienes tu parte de responsabilidad sobre él. Tienes que hacer tareas creativas, no tareas aburridas.

Y aquí llega mi primera duda. Porque la vida real... ¿es así?. ¿No aparecen día sí y día también tareas soporíferamente aburridas, que no se pueden atajar haciendo de otra forma y que además no hay más remedio que hacerlas?. ¿No hay un montón de gente que se ha metido en el desarrollo porque da de comer, pero que realmente ni se sienten especialmente motivados ni les interesa sentirse así, sino que se prefieren limitarse a "cumplir órdenes"?. ¿Dónde encaja todo esto en las metodologías ágiles?.

2. Muerte al papel (efecto Fahrenheit 451)

Tradicionalmente creo que ha habido dos grandes problemas con la documentación. El primero es que muchas metodologías "de las antiguas" requerían una cantidad indecente de documentación. Yo personalmente he trabajado en proyectos en los que el equipo que había se tiraba más de un año haciendo toneladas de documentación, y cuando se querían dar cuenta no habían hecho nada de software real y el tiempo se estaba acabando. Al final resulta que se tiene que hacer todo el desarrollo corriendo y sin que la mayor parte de la documentación existente ayudase demasiado. Es una pérdida de tiempo y de energías, y además, desmotiva.

Pero el segundo problema creo que es aún peor, y tiene que ver con el paso del tiempo. Ocurre porque el software y la documentación son entidades diferentes. Están disociadas. Llega un momento en que, una vez entregada la primera fase del proyecto, dentro del mantenimiento se modifica el software pero no la documentación. ¿Para qué sirve una documentación que no está actualizada?.

Para resolver esto, en mi opinión lo que hay que hacer es integrar la documentación en el propio software. Olvidar la idea del "documento". Un gran ejemplo de esto es el JavaDoc. Pero creo que no basta con eso. Creo que aún nos falta subir más de nivel de abstracción. En mi segundo artículo sobre UML ya mencionaba la importancia de que los diagramas UML estuvieran integrados con el código Java, usando lo que se llamó (entre otros nombres) "live round-trip". Y aún podría ir más allá, porque también tengo mis propias ideas sobre el análisis de requisitos integrado con el código. Pero eso ya lo contaré en otra ocasión (me queda mucho de lo que hablar hasta llegar ahí)...

En este punto de la documentación, la verdad es que mis dudas son menores. Lo único que me pregunto es: ¿la gente estará siendo capaz de medir bien y ser racional con la documentación que se produce para el software?. En esto de la documentación, yo casi siempre lo que he visto han sido extremos: o te obligan a documentar demasiado, o no se documenta nada. Es decir, ¿se estará usando esto como excusa para no documentar nada de nada?. ¿Ni unos mínimos JavaDoc, ni una mínima documentación de intenciones, nada de nada?.

3. El cliente es tu amigo

Tengo que reconocer que la idea es muy buena. Es difícil que el software que se produzca satisfaga al cliente y cumpla sus necesidades cuando el cliente no está ahí siempre que haya alguna duda. Si hay que esperar a que haya una reunión para preguntarle, todo se retrasa. Muchas veces se tira "por el camino del medio", acertando en algunas ocasiones y en otras no. Muchas veces esas reuniones, cuando por fin llegan, se estiran y estiran y cuando sales te das cuenta de que no le has preguntado nada de lo que necesitabas saber (y que te duele la cabeza, además). Pero también muchas, muchas veces, el cliente se para a mirar lo que llevas hecho cuando sólo quedan dos semanas para la puesta en producción. Y entonces decide cambiarlo todo.

La idea, como digo, es buenísima, que el cliente participe dentro del propio desarrollo, que haya una comunicación frecuente con él y pueda resolver todas las dudas rápidamente. Pero... ¿es realista en la mayor parte de las ocasiones?. ¿De verdad los clientes se prestan a colaborar en los proyectos?. En mi experiencia, muchos clientes tienen su propio trabajo que sacar adelante, y consideran que no tienen tiempo para eso. Consideran que es tu problema. No entienden la importancia de ese tema. Ya te han contado qué es lo que necesitan, así que déjales en paz. Por supuesto, hay clientes y clientes. Pero me surgen muchas dudas sobre la resistencia que presentarán muchos clientes en contra de esa colaboración.

4. Be water, my friend

Ya he comentado en alguna ocasión que el desarrollo de un producto de software es un proceso de aprendizaje. Según se va profundizando en él, mejor se va entendiendo, y al hacerlo se van descubriendo nuevas implicaciones del desarrollo. Cosas nuevas que hay que hacer, o cosas que cuestan mucho más de lo que se había pensado al principio porque obligan a cambiar otras cosas o no se pueden plantear como se tenía previsto. Esto hace que los planes a largo plazo (e incluso a medio, y diría que muchas veces hasta a corto) sean difíciles de seguir, porque lo normal es que se descubran cosas nuevas sobre la marcha, y en ese caso siempre hay que acabar sacrificando algo. O el proyecto sale menos rentable, o se resiente la calidad del producto, o (más a menudo de lo que debería, sobre todo en consultoras) lo que se sacrifica es el tiempo de los programadores, que acaban haciendo horas no retribuidas como campeones, apelando al "compromiso con la empresa".

En cualquiera de los casos, se propaga un sentimiento de culpabilidad: "alguien ha hecho algo mal". "Esto no debe seguir así". "A partir de ahora vamos a hacer las cosas bien, y vamos a... planificar más cosas y mejor".

Las metodologías ágiles afrontan este problema dándole más importancia a la "respuesta al cambio" que al plan. Esto tiene una implicación enorme sobre la forma de trabajar de las empresas con sus clientes: requiere cambiar la forma en la que se hacen los contratos con el cliente. Ya no valen contratos cerrados, tipo "me haces todas estas funcionalidades en este tiempo y yo te pago esto". Nos vamos a una facturación por tiempo trabajado. Por un lado eso invalida directamente este tipo de desarrollos con determinado tipo de contrataciones, por ejemplo, cualquier proyecto con la administración pública, que tiene que ser cerrado por definición. Aparte de eso, ¿cuál es el problema de esto?. Que requiere una gran confianza. Confianza del cliente hacia la empresa del desarrollo, para que no piense "estos me están queriendo timar, me están cobrando una barbaridad para lo que están haciendo". Confianza del gestor de la empresa de desarrollo con el equipo que va a programarlo, para que no piense "estos se están pasando el día tocándose las narices, y el cliente se va a cabrear y nos va a dejar tirados".


¿Y en el fondo, no es ese el principal problema que tienen las metodologías ágiles? (aparte del hecho de que hay un conjunto grande de gente y/o situaciones para las que sencillamente no valen). Que requieren confianza. Que requieren querer hacerlo. Confianza del programador en el resto del equipo, confianza en que se está haciendo lo correcto, confianza en que la dirección lo va a soportar, confianza en que el cliente lo va a apoyar. Confianza de la dirección en el equipo de desarrollo, confianza en que va a funcionar bien, confianza en que al cliente le va a gustar. En definitiva, requieren que todos los implicados crean en lo que se está haciendo, desde el cliente que pone el dinero hasta el becario que echa una mano con lo que sea. Requieren que todos crean en el trabajo de ese equipo y de todos y cada uno de sus componentes.

¿Y sabéis qué?. Que yo me creo todo eso. Creo en la sinergia. Creo en que cada persona es capaz finalmente de asumir responsabilidades por sí misma, cuando se le otorga la confianza para que lo haga.

Pero no estoy seguro de que el mundo esté preparado para ello. Me parece un cambio de orientación demasiado grande y que afecta a demasiadas partes. Tengo muchas dudas. Me cuesta creer que las metodologías ágiles se estén usando de forma generalizada.

Así que si estás leyendo esto y has tenido ocasión de trabajar en algún proyecto siguiendo una metodología ágil, por favor, deja un comentario y comparte tu experiencia. Cuéntanos cómo convenciste a tus clientes y a tus jefes. Yo estoy dispuesto a apurar mi petaca de whisky y gritar: "¡Cambiemos el mundo!".


NOTA: Sí, los chistecillos son míos, haciendo un poco el tonto con el Inkscape juntando personajes que he cogido de por aquí y por allá (he procurado que fueran todos de dominio público). La mayor parte proceden de Open ClipArt.