Tinselcity

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
old:ay_ay_ay_agile [2020/10/07 02:09]
flynn
old:ay_ay_ay_agile [2021/03/17 15:26] (actual)
flynn
Línea 378: Línea 378:
 El inicio de la escena tiene algunas variaciones. En ocasiones el Arquitecto está en su mesa y alguien acude a preguntarle algo. Otras veces el Arquitecto asiste a una reunión con cuatro o cinco personas más. Otra variante común es que el Arquitecto esté haciendo su //paseillo// mirando entre las mesas, buscando alguien con quien gastar un par de horas sin hacer nada de particular. Sea como sea, la conversación empieza. Y luego continua. Y sigue continuando y continuando, dando vueltas a lo mismo o a cosas nuevas pero sin llegar nunca a una conclusión. El inicio de la escena tiene algunas variaciones. En ocasiones el Arquitecto está en su mesa y alguien acude a preguntarle algo. Otras veces el Arquitecto asiste a una reunión con cuatro o cinco personas más. Otra variante común es que el Arquitecto esté haciendo su //paseillo// mirando entre las mesas, buscando alguien con quien gastar un par de horas sin hacer nada de particular. Sea como sea, la conversación empieza. Y luego continua. Y sigue continuando y continuando, dando vueltas a lo mismo o a cosas nuevas pero sin llegar nunca a una conclusión.
  
-Los demás sí que llegan a la conclusión. Yo mismo he llegado ya muchas veces a la conclusión de que el Arquitecto en realidad solo está hablando //delante de ti// pero no está realmente hablando //contigo//. Habla consigo mismo. Pero no, no me referia a esto. Los demás llegan a una conclusión. Después de 30 minutos o de 5 horas, les oyes decir "Bueno, pues entonces hacemos esto" o "Pues voy a hacer esa opción" o "Lo pruebo y te digo algo" u otras cosas que casi rozan el "no queda más que decir; se acabó; damos por concluída la conversación". No solo eso, sino que terminan la conversación físicamente. //Se van//. Se alejan del Arquitecto y se van a su sitio. O se levantan de la reunión y recogen sus cosas. O a veces se levantan de su proprio puesto para huir hacia algún refugio como el baño, un cigarrillo, o alguna otra excusa para poner distancia entre ellos.+Los demás sí que llegan a la conclusión. Yo mismo he llegado ya muchas veces a la conclusión de que el Arquitecto en realidad solo está hablando //delante de ti// pero no está realmente hablando //contigo//. Habla consigo mismo. Pero no, no me refería a esto. Los demás llegan a una conclusión. Después de 30 minutos o de 5 horas, les oyes decir "Bueno, pues entonces hacemos esto" o "Pues voy a hacer esa opción" o "Lo pruebo y te digo algo" u otras cosas que casi rozan el "no queda más que decir; se acabó; damos por concluida la conversación". No solo eso, sino que terminan la conversación físicamente. //Se van//. Se alejan del Arquitecto y se van a su sitio. O se levantan de la reunión y recogen sus cosas. O a veces se levantan de su proprio puesto para huir hacia algún refugio como el baño, un cigarrillo, o alguna otra excusa para poner distancia entre ellos.
  
 Y entonces... el Arquitecto va detrás. Y entonces... el Arquitecto va detrás.
  
-Se levanta también y se va detrás y empieza a repetir algo de lo que ya se ha dicho para hacer que la conversación continue, aunque sea en otro lugar. La reunión pasa de la sala al pasillo. O de estar sentados a una mesa a estar de pie a dos metros de esa mesa. Del puesto de trabajo del Arquitecto al de la persona que vino a preguntar. Recuerdo que por lo menos en una ocasión le he visto decir que "ah, pues voy yo también al baño" para continuar la conversación antes, durante y después de hacer sus cosas.+Se levanta también y se va detrás y empieza a repetir algo de lo que ya se ha dicho para hacer que la conversación continúe, aunque sea en otro lugar. La reunión pasa de la sala al pasillo. O de estar sentados a una mesa a estar de pie a dos metros de esa mesa. Del puesto de trabajo del Arquitecto al de la persona que vino a preguntar. Recuerdo que por lo menos en una ocasión le he visto decir que "ah, pues voy yo también al baño" para continuar la conversación antes, durante y después de hacer sus cosas.
  
 La única estrategia que casi siempre es efectiva es el silencio. Cuando termino de hablar, no digo nada más. Y si él dice algo, yo no. Solo entonces da la conversación por agotada... O casi. Porque como mi sitio está frente al suyo, a veces al cabo de un minuto o así dice algo más y lo dice en un tono y a un volumen calculado perfectamente para que se pueda interpretar tanto como que sigue hablando conmigo como que simplemente hace un comentario casual en voz alta para sí mismo. La única estrategia que casi siempre es efectiva es el silencio. Cuando termino de hablar, no digo nada más. Y si él dice algo, yo no. Solo entonces da la conversación por agotada... O casi. Porque como mi sitio está frente al suyo, a veces al cabo de un minuto o así dice algo más y lo dice en un tono y a un volumen calculado perfectamente para que se pueda interpretar tanto como que sigue hablando conmigo como que simplemente hace un comentario casual en voz alta para sí mismo.
Línea 392: Línea 392:
 Un día el Arquitecto me enseña una de sus chapuzas. Una particularmente mala mezclando Promesas y callbacks cuando en realidad no necesita ninguna de las dos. Un día el Arquitecto me enseña una de sus chapuzas. Una particularmente mala mezclando Promesas y callbacks cuando en realidad no necesita ninguna de las dos.
  
-Se lo digo, suavemente, sugiriendo una solución mucho más simple. Dice algo como "pero es que es asíncrono; necesito la promesa...". Se lo enseño, intentanto que no parezca que su código es una estupidez absoluta sino simplemente que se puede hacer más fácil de otra forma.+Se lo digo, suavemente, sugiriendo una solución mucho más simple. Dice algo como "pero es que es asíncrono; necesito la promesa...". Se lo enseño, intentando que no parezca que su código es una estupidez absoluta sino simplemente que se puede hacer más fácil de otra forma.
  
 No se queda muy convencido, pero me dice: No se queda muy convencido, pero me dice:
Línea 430: Línea 430:
 >> Blabla - más >> Blabla - más
 > Aha, pero ya lo depuro yo... > Aha, pero ya lo depuro yo...
->> Blablabla - le quita el ratón de la mano y añade: - dale Alt Shift P.+>> Blablabla - le arranca literalmente el ratón de la mano y añade: - Dale Alt Shift P.
 > . . . > . . .
  
Línea 507: Línea 507:
 Existe una tendencia muy clara de los desarrolladores del equipo a no interesarse lo más mínimo por las herramientas que usan. No intervienen en su instalación, ni en su configuración, ni en nada. Existe una tendencia muy clara de los desarrolladores del equipo a no interesarse lo más mínimo por las herramientas que usan. No intervienen en su instalación, ni en su configuración, ni en nada.
  
-Hace un rato Reginald ha ejecutado Maven y le ha dado un error. Ha avisado a la persona "de sistemas" para que se lo arregle y mientras se lo arregla ha salido a fumar.+Hace un rato Montgomery ha ejecutado Maven y le ha dado un error. Ha avisado a la persona "de sistemas" para que se lo arregle y mientras se lo arregla ha salido a fumar.
  
 ---- ----
Línea 697: Línea 697:
  
  
-Edit: Crystal me dice que no me sorprenda. Y que no espere respuesta. Y que si incluyo al Traje en los mails tampoco espere respuesta suya.+Edit: Chrystal me dice que no me sorprenda. Y que no espere respuesta. Y que si incluyo al Traje en los mails tampoco espere respuesta suya.
  
 ---- ----
Línea 703: Línea 703:
 No-gestión de la crisis... No-gestión de la crisis...
  
-Esto me lo cuenta Henry. Crystal nos decía que si acaso nos sorprendía la (no-)respuesta que estábamos teniendo. Henry dice...+Esto me lo cuenta Henry. Chrystal nos decía que si acaso nos sorprendía la (no-)respuesta que estábamos teniendo. Henry dice...
  
 > ¿Sorprendido? Me sorprendí por última vez el martes cuando le pedí a Karen que organizase los turnos para ir a la oficina y me contestó: "A ver, esto es un equipo Scrum; organizaros vosotros. ¡Ya tenéis que saber hacerlo!" y miró complacida a [el otro traje] que asintió con la cabeza. Después me miraron como si hubiera planteado una estupidez. Desde ese momento me van a sorprender ya pocas cosas. > ¿Sorprendido? Me sorprendí por última vez el martes cuando le pedí a Karen que organizase los turnos para ir a la oficina y me contestó: "A ver, esto es un equipo Scrum; organizaros vosotros. ¡Ya tenéis que saber hacerlo!" y miró complacida a [el otro traje] que asintió con la cabeza. Después me miraron como si hubiera planteado una estupidez. Desde ese momento me van a sorprender ya pocas cosas.
Línea 855: Línea 855:
 No me meto en la conversación porque sé que no acabaría bien, pero todos sabemos perfectamente que el Arquitecto está en casa porque es el Arquitecto. No me meto en la conversación porque sé que no acabaría bien, pero todos sabemos perfectamente que el Arquitecto está en casa porque es el Arquitecto.
  
-Jenny comenta que lo de hacer turno hasta las nueve de la noche le dificulta mucho cuidar de su hijo y que eso les pasa a varios. El Traje dice casualmente que eso //"no es un riesgo para el cliente"//. Mirando en el diccionario escum-español veo que la expresión significa más o menos "me importan una mierda tus problemas" o "¿tengo cara de que me importen a mi tus problemas?", según la entonación.+Jenny comenta que lo de hacer turno hasta las nueve de la noche le dificulta mucho cuidar de su hijo y que eso les pasa a varios. El Traje dice casualmente que eso //"no es un riesgo para el cliente"//. Mirando en el diccionario scum-español veo que la expresión significa más o menos "me importan una mierda tus problemas" o "¿tengo cara de que me importen a mi tus problemas?", según la entonación.
  
 ---- ----
Línea 964: Línea 964:
 Creo que una de las cosas que más me llama la atención del proyecto es la absurda y ridícula consideración que se tiene del tiempo. Creo que una de las cosas que más me llama la atención del proyecto es la absurda y ridícula consideración que se tiene del tiempo.
  
-Por un lado, se obliga a los desarrolladores y analistas a ficher múltiples veces y a imputar tiempos a tareas teniendo que cuadrar estos tiempos con precisión de minutos en un mes. Vamos, que no puede haber un descuadre de más de un minuto o dos en los tiempos registrados cada mes.+Por un lado, se obliga a los desarrolladores y analistas a fichar múltiples veces y a imputar tiempos a tareas teniendo que cuadrar estos tiempos con precisión de minutos en un mes. Vamos, que no puede haber un descuadre de más de un minuto o dos en los tiempos registrados cada mes.
  
 Esto, en sí mismo, es algo que podría, haciendo algo de esfuerzo, llegar a aceptar. Personalmente no creo que sea posible registrar los tiempos con esa precisión, particularmente en un entorno en el que muchas tareas ni siquiera están definidas. Al final lo que ocurre es que todo el mundo //rellena// tareas. Es decir, los tiempos //cuadran// pero no son reales en absoluto. Si asumimos esa mentira, bueno, es algo que por lo menos se puede hacer. Esto, en sí mismo, es algo que podría, haciendo algo de esfuerzo, llegar a aceptar. Personalmente no creo que sea posible registrar los tiempos con esa precisión, particularmente en un entorno en el que muchas tareas ni siquiera están definidas. Al final lo que ocurre es que todo el mundo //rellena// tareas. Es decir, los tiempos //cuadran// pero no son reales en absoluto. Si asumimos esa mentira, bueno, es algo que por lo menos se puede hacer.
Línea 1025: Línea 1025:
 Esto es lo que ocurre cada tres semanas, con cada nuevo //sprint//((Los números son reales, sacados del último mensaje de estos, el de ayer. Y suelen ser números parecidos a estos, sí. La mayoría de las cosas se van arrastrando y he visto tareas que se llevan arrastrando más de dos años sin que nadie se plantee ni hacerlas ni eliminarlas)). No hay, obviamente, ningún tipo de planificación de los //sprints//. Tampoco hay ningún tipo de revisión al cierre de un //sprint//. Este mensaje es lo único que marca, de algún modo, un //sprint//. Esto es lo que ocurre cada tres semanas, con cada nuevo //sprint//((Los números son reales, sacados del último mensaje de estos, el de ayer. Y suelen ser números parecidos a estos, sí. La mayoría de las cosas se van arrastrando y he visto tareas que se llevan arrastrando más de dos años sin que nadie se plantee ni hacerlas ni eliminarlas)). No hay, obviamente, ningún tipo de planificación de los //sprints//. Tampoco hay ningún tipo de revisión al cierre de un //sprint//. Este mensaje es lo único que marca, de algún modo, un //sprint//.
  
-Los //sprints// están agrupados en dos ciclos de entregas anuales. Eso supone que hay aproximadamente unos 8 o 9 //sprints// por ciclo. No se hace tampoco ninguna planificación con el equipo al principio de uno de estos ciclos. De hecho, el principio de un ciclo queda difuminado por dos detalles: antes de que empiece ya hay gente del equipo trabajando en la siguiente versión; y, después de que temrine sigue habiendo gente trabajando en la versión anterior. Yo mismo he hecho tareas((y digo tareas, no corrección de errores)) de una versión anterior unos 3 meses después de la fecha de entrega de esa versión, y he hecho tareas que estaban planificadas pero no se entregarán hasta dentro de casi un año.+Los //sprints// están agrupados en dos ciclos de entregas anuales. Eso supone que hay aproximadamente unos 8 o 9 //sprints// por ciclo. No se hace tampoco ninguna planificación con el equipo al principio de uno de estos ciclos. De hecho, el principio de un ciclo queda difuminado por dos detalles: antes de que empiece ya hay gente del equipo trabajando en la siguiente versión; y, después de que termine sigue habiendo gente trabajando en la versión anterior. Yo mismo he hecho tareas((y digo tareas, no corrección de errores)) de una versión anterior unos 3 meses después de la fecha de entrega de esa versión, y he hecho tareas que estaban planificadas pero no se entregarán hasta dentro de casi un año.
  
 Si no hay nada de esa planificación, ¿cómo ocurren las cosas? Bueno, ocurren porque como equipo Agile no somos ni Agile ni equipo. Cada //analista// hace su planificación como quiere. Que generalmente significa que no hace planificación en absoluto sino que va directamente al desarrollador con el que suele trabajar o que le cae bien o lo que sea y le dice que le va a pasar algunas tareas y que ya las irán viendo. Si no hay nada de esa planificación, ¿cómo ocurren las cosas? Bueno, ocurren porque como equipo Agile no somos ni Agile ni equipo. Cada //analista// hace su planificación como quiere. Que generalmente significa que no hace planificación en absoluto sino que va directamente al desarrollador con el que suele trabajar o que le cae bien o lo que sea y le dice que le va a pasar algunas tareas y que ya las irán viendo.
Línea 1242: Línea 1242:
 total = parseFloat(24); total = parseFloat(24);
 </sxh> </sxh>
 +
 +----
 +
 +Reconozco que me empieza a costar bastante tratar con Monty...
 +
 +Hace unos seis meses, Monty, Edward y yo aceptamos hacernos cargo (por lo menos temporalmente) de una serie de tareas mayormente de maquetación y algunas cosas más. Son tareas bastante aburridas, la verdad. Ninguno de los tres quería tener que cargar con todo y tampoco el Traje quería tener que dedicar a una única persona de forma exclusiva. Así que entre todos acrodamos que se haría así, conjuntamente.
 +
 +Se creó un usuario genérico en Jira al que se asignarían todas esas tareas y Monty, Edward y yo las iríamos cogiendo sin mucha ceremonia, simplemente según fueramos viéndolas llegar.
 +
 +Seis meses después yo no estaba demasiado contento con algún detalle. Les digo a Edward y Monty que me gustaría que lo habláramos. Les explico que no busco un confrontamiento pero que en seis meses yo he cogido 138 tareas de estas, Edward 78 y Monty ha cogido... //25//.
 +
 +Lo primero que hace Monty es dudar de los números. Los verifica. Luego sugiere que a lo mejor sus 25 tareas son mucho más complejas... pero rápidamente abandona esa idea. Me imagino que intuye que si sigue por ese camino le voy a tener que recordar todas esas veces en que ha perdido horas, días, e incluso semanas haciendo algo que después, cuando ha aceptado hacer como le decía, ha tardado 30 minutos como mucho.
 +
 +Luego Monty confiesa, con toda normalidad, que bueno, que es que él no mira esas tareas desde hace meses. En fin, como digo no busco el confrontamiento, así que para no tener que decirle nada desagradable, le ofrezco que sugiera alguna idea sobre qué podemos hacer y cómo podemos mejorar esto.
 +
 +Monty dice que... vaya, Monty dice que a él le parecería bien que siguiéramos así como lo hemos estado haciendo hasta ahora.
 +
 +Ni siquiera se le ocurre tratar de vestirlo un poco bonito. No se le ocurre decir que sigamos así pero que va a hacer un esfuerzo por coger más tareas ni nada similar. Solo que sigamos así, que a él eso le parece lo mejor.
 +
 +A veces tengo dudas sobre Monty. No sé si es simplemente idiota, si es que no es capaz de entender lo que le están diciendo, o si realmente tiene esta actitud intencionadamente y se hace el idiota.
 +
 +----
 +
 +He encontrado //otro// invento del Arquitecto basado en usar ''eval''.
 +
 +Resulta que hay una media docena de sitios en la aplicación donde hay una pequeña lista de cosas -normalmente enlaces-. Y en un momento dado a alguien por algún motivo se le ocurrió que sería interesante poder ordenar esas listas de varias formas.
 +
 +Estas listas se pintaban desde JavaScript, a base de pasar un //array// con los enlaces y sus textos. La solución parece fácil. Se hace un...
 +
 +<sxh javascript>
 +arrayDeEnlaces.sort(ordenacion);
 +</sxh>
 +
 +...y se le pasa la función ''ordenacion'' como parámetro. El problema es que el Arquitecto no debía saber que se pueden pasar funciones de aquí para allá. Supongo, no sé. Porque la solución del Arquitecto es pasar //el nombre de la función// como una cadena. Y luego, hacer esto otro:
 +
 +<sxh javascript>
 +arrayDeEnlaces.sort(eval(ordenacion));
 +</sxh>
 +
 +Esto además es simpático porque luego resulta que salvo en 1 caso, nunca se pasa nada en ''ordenacion''. //Shrug//
 +
 +----
 +
 +Varias veces en el último año me he preguntado cómo se ha podido llegar al estado actual del equipo en el que todos creen que la mejor forma de hacer cualquier cosa es siempre a base de repetir múltiples veces grandes cantidades de código. En un momento dado llegué a la conclusión de que no había ningún motivo particular, que simplemente la mayoría no sabe qué está haciendo y por eso la forma más natural era copiar algo que ya funcionara, cambiarle los detalles que no coinciden y luego aporrearlo hasta volver a hacerlo funcionar.
 +
 +Pero no, resulta que no es tan casual ni tan fortuito.
 +
 +En una unidad compartida hay una serie de //"documentos"// de varios cursos internos. Hasta ahora siempre los había ignorado un poco. Sabía que estaban ahí y sabía que esos cursos habían existido, pero fue antes de que yo viniera y los documentos son... bueno, no son muy buenos, la verdad.
 +
 +Hoy, por algún motivo, he decidido echar un ojo a uno de esos documentos. Y luego a otro. Y a otro más. Y al final, he mirado casi todos.
 +
 +La mayoría son documentos bastante pobres. Hay, por ejemplo, una //"Guía para la optimización de consultas SQL"// que, en un total de **tres** páginas -incluyendo portada- se limita a decir que existe ''EXPLAIN PLAN'' y que si sale un coste de más de 50 se avise al Arquitecto para intentar optimizar esa consulta. En general, poco detalle y muchos párrafos genéricos que parecen copiados de Wikipedia o de algún libro de programación de hace 20 años.
 +
 +Hay dos grupos. Uno es más formal, son documentos que se comparten con el cliente. El otro son una serie de documentos más prácticos y más informales. Son documentos //de desarrollo//, que explican cómo se hacen algunas cosas habituales en el proyecto. En general, simplemente no son muy buenos. Pero leyendo más, comparando varios, aparece algún patrón, y uno muy evidente es que todos se basan en copiar y pegar. Lo promueven activamente. Definen la forma correcta de hacer esas tareas como una en la que se terminan copiando fácilmente dos, tres, cuatro mil líneas de código y cambiando algunos pocos valores aquí y allí.
 +
 +No es casual. No ha ocurrido porque el equipo no esté preparado para otra cosa. Esto es exactamente lo que se ha implantado y promovido intencionadamente.
 +
 +----
 +
 +Mientras tanto, me encuentro esto en el código:
 +
 +<sxh java>
 +int i = 0;
 +while (i<unaLista.size()) {
 +   TablaElementoVO elementoVO = (TablaElementoVO) unaLista.get(i);
 +
 +  if (elementoVO.getCodigo().equals("O")) {
 +     unaLista.remove(i);
 +     i--;
 +   }
 +   if (elementoVO.getCodigo().equals("S")) {
 +     unaLista.remove(i);
 +     i--;
 +   }
 +   if (elementoVO.getCodigo().equals("T")) {
 +     unaLista.remove(i);
 +     i--;
 +   }
 +
 +   // etc hasta una docena de veces aproximadamente
 +
 +   i++;
 + }
 +</sxh>
 +
 +Esto, junto a una variante en la que utilizan un ''for'' en lugar de un ''while'', está por todas partes. Lo usan para filtrar algunas ''ArrayList'' antes de devolverlas al usuario.
 +
 +Mando un mail al equipo explicando varias opciones. Usar un iterador, que es lo más parecido a lo que están haciendo pero se ahorran la estupidez de andar moviendo el índice ''i'' a mano en medio del bucle. O usar ''Collection#removeIf'', que estamos ya desde hace tiempo con Java 8. O usar el ''CollectionUtils'' de Spring, ya que la aplicación está construida sobre Spring aunque no lo parezca. Y un par de opciones también para evitar todos esos ''if'' repetitivos y que más de una vez ya han dado lugar a incidencias. Incluyo al Arquitecto en el mail, aunque sé que no va a contestar porque el Arquitecto está por encima de estas nimiedades y porque seguramente necesitará unos días para asimilar que su código -especialmente la parte de Java- no está tan bien como él dice. Y además porque es el único que está en casa desde hace 6 meses mientras todos los demás estamos trabajando presencialmente y hay que mantenerle informado.
 +
 +Cuando mando estos mails suele haber 1 respuesta, la de la única persona que parece tener un interés genuino por mejorar cómo se hacen las cosas. El resto, si llega a leerlo, lo ignorará. O, como mucho, aprovechará el tema para dejar caer -al pasar casualmente cerca de mi- algún comentario como "Si es que cada día nos dicen que hagamos las cosas de una forma" o "Yo voy a seguir haciendo las cosas como me dé la gana".
 +
 +----
 +
 +También mando un mail a Montgomery y a Edward. Estamos haciendo los tres un grupo de pantallas que están relacionadas con una misma funcionalidad. Esto, normalmente, no significa mucho. Quiero decir, la costumbre aquí es que se ordenan las cosas en un árbol de carpetas que tiene 2 niveles y dentro de eso //a mogollón//.
 +
 +Pero lo hablamos entre los tres y decidimos que estas pantallas nuevas las íbamos a ordenar un poco. Ambos tenían alguna otra tarea, así que quedamos en que yo hoy prepararía un esqueleto de una de las pantallas y lo compartiría con ellos para que sigamos todos el mismo esquema. Monty dice que le parece bien. Comenta que tiene todavía tarea para todo este día, así que no hay prisa. A lo largo de la mañana Monty me pregunta un total de tres veces que si ya lo he subido, que quiere verlo. Monty es un poco imbécil, pero no se lo digo. Pacientemente le digo las tres veces que ya le avisaré yo, que se ponga con eso otro que tenía.
 +
 +Total, que hago ese esqueleto guía y les mando un mail explicando donde he puesto todos y cada uno de los ficheros. Los JSPs van en //esta// carpeta que está aquí, los Actions que hagáis, en //esta// otra de allá. Luego tenéis que editar //este// XML de aquí y //este// otro de allí. Así todo, muy detallado con lo que hay que poner y dónde hay que ponerlo.
 +
 +Les digo que cuando lo lean, si algo no está claro que pregunten.
 +
 +Monty contesta rápidamente.
 +
 +> Yo no tengo preguntas. Me parece todo perfecto.
 +
 +Unos diez segundos después, añade:
 +
 +> Bueno, ¿dónde van los JSPs? Porque es que yo los míos los he puesto donde he querido.
 +
 +Le contesto y le digo que van en //esta carpeta carpeta que está aquí//. Ni siquiera menciono que había dicho que él tenía tarea y que todavía no iba a empezar con esto.
 +
 +> Aaaaaah, ok. Aaaaah, vale. Ya entiendo. - dice Monty
 +
 +Acompañando al mail, he subido al repositorio el esqueleto. Para crear las carpetas y poner un ejemplo para que se vea dónde va cada cosa. El mail empieza diciendo "Hay un esqueleto vacío en el repo. **No** funciona, es un esqueleto. No se usa aún en ningún sitio.". Así, con negrita incluída. No es la primera frase del mail, pero debe ser la segunda.
 +
 +Dos minutos después de que Monty diga que ya ha entendido, se levanta de su sitio y se acerca. Me pregunta que dónde se puede ver funcionando lo que he subido, para probarlo y ver cómo va.
 +
 +Monty es imbécil. No se lo digo, pero me entran //muchas// ganas de hacerlo.
 +
 +----
 +
 +Creo que aquí es donde acaba esta historia.
 +
 +El otro día, los dos Trajes me convocan a una reunión con media hora de aviso. Quieren hacer un seguimiento de mi trabajo. Al final, el tema de la reunión llega a mi compromiso, a si estoy comprometido para abordar la "definición de una nueva arquitectura con el Arquitecto".
 +
 +Inicialmente intento que me aclaren qué es lo que entienden ellos como "la definición de una arquitectura", especialmente porque el Arquitecto, en aquella reunión que tuvimos hace meses en la que lo único que quería era que yo dijera que me parecía bien su decisión, ya había tomado la mayoría de decisiones sobre qué usar y qué hacer. Pero esto no lleva a ningún sitio porque el Traje no tiene realmente ningún conocimiento técnico y no sabe qué es "definir una arquitectura". Lo único que está claro es cómo quiere que ocurra. Quiere un papel de Arquitecto clásico (y erróneo, claro). Quiere ese Arquitecto que se encierra en una torre y, aislado de la realidad, //piensa cosas//. Luego suelta mierdas a los desarrolladores y estos se apañan.
 +
 +No me llama mucho la idea, pero no la discuto. De hecho, ni siquiera comento estas cosas.
 +
 +En lugar de eso, les pregunto si recuerdan la reunión que tuvimos hace ya más de 6 meses. Les recuerdo que ya entonces les avisé que si querían mi compromiso, tendría que cambiar //alguna cosa//. Les pregunto:
 +
 +> ¿Creéis vosotros que ha cambiado alguna cosa? ¿Creéis que hemos mejorado en //algo//?
 +
 +El Traje hace una broma sobre el hecho de que ya no hay música en la sala. No me hace gracia. Insisto en la pregunta. El Traje me explica que:
 +
 +  * No, probablemente no haya habido ninguna mejora.
 +  * Tampoco va a haber nignuna mejora en el futuro, ni va a cambiar nada porque algunas cosas no tienen intención de cambiarlas y otras "es que son muy difíciles" de cambiar y por tanto ya ni se plantean intentarlo.
 +  * A lo mejor es que yo no tengo toda la información de por qué las cosas son así. Dice esto, pero, por supuesto, no me explica esa información tan misteriosa.
 +  * Le parece inaudito que alguien pretenda que se cambien y mejoren las formas de trabajar para aceptar seguir trabajando aquí. //"Nunca en mi vida había oído algo así"// - dice.
 +
 +No pido ningún cambio específico. No pido tampoco que se realice algún cambio en un determinado plazo. Pero es que no ofrecen ni siquiera la intención de cambiar nada. //"Esto es lo que hay y nada va a cambiar."//
 +
 +La próxima semana tendré que comunicar mi baja.
 +
 +----
 +
 +Una vez entras en la aplicación, aterrizas en una página con diferentes paneles de información y acciones. En uno de esos paneles hay "herramientas externas". Son una serie de iconos que enlazan con otras aplicaciones relacionadas. No todos los usuarios tienen acceso a todas las herramientas, pero pueden solicitarlo. Así que cada icono tiene 2 versiones, una activa (normal) y otra desactivada (gris).
 + 
 +Hay una carpeta donde se guardan estas imágenes. Todos los ficheros de estos iconos (unos 20) siguen una misma nomenclatura: ''portada_nombreAplicacion.gif'' para el normal y ''portada_nombreAplicacionDes.gif'' para el desactivado/gris.
 +
 +Hoy Monty ha recibido la tarea de renovar uno de estos iconos. No cambia nada más que el icono. El enlace es igual, la aplicación es la misma. Solo cambia el icono. Media hora después, Gerald le ha hecho notar a Monty que necesita poner también la versión en gris. Como Monty estaba ya un poco cansado, ha terminado Gerald la tarea.
 +
 +Así que ahora hay unos 20 iconos con un nombre como ''portada_nombre.gif'' y ''portada_nombreDes.gif'', uno que se llama ''transporteAll.gif'' y su versión gris que se llama ''transporteDesactivado.gif''. Por supuesto, el icono antiguo, que ya no se usa, sigue ahí en el repositorio, porque si la consistencia importa poco, borrar lo que ya no se usa importa incluso menos.
 +
 +Ya solo me quedan 4 semanas aquí.
 +
 +----
 +
 +Hay un wiki para el equipo de desarrollo.
 +
 +Bueno, hay mucha historia ahí, claro, porque a nadie parece importarle el wiki. Pero bueno, eso ya no me preocupa. El wiki tiene documentación de desarrollo, explica cómo hacer bastantes cosas de "la parte de front".
 +
 +Pero el wiki tiene una pequeña trampa. Como vi que se empeñaban en copiar y pegar las cosas sin entenderlas. Poco a poco fui cambiando los ejemplos de código por imágenes. Así como mínimo tienen que teclearlo y quizá con eso se les quede un poco más en la cabeza. Eh, no creo, pero ojalá. El caso es que hay una parte de la documentación que no la he escrito yo sino la diseñadora/maquetadora que nos dejó hace medio año. Antes de irse, dejó cinco o seis páginas de documentación de "interfaz de usuario". La mayoría son imágenes de cómo deben quedar las cosas, pero en alguna de las páginas también hay algún trozo de código que puso ella. El código no es bueno, pero esos trozos de código no los cambié por imágenes porque me pareció que no merecía la pena y que se entendería que no era código bueno porque, de hecho, es bastante malo.
 +
 +Pues hoy Monty ha ido directo a copiar uno de esos trozos de código.
 +
 +Por suerte, Edward estaba ahí.
 +
 +>No, no, espera. Este código no está bien. Mira, hay un ''<img>'' con el ''onClick'' puesto ahí directamente. Eso **claramente** no puede ser así.
 +>>Ah - dice Monty
 +
 +Me lo comentan y les digo que sí, que efectivamente ese código no esta bien y no se debe copiar. //"Ah, vale, vale"// - dice Monty.
 +
 +Por si acaso, edito el wiki y marco las cuatro páginas con un aviso grande, rojo y en negrita que dice que el código no es bueno y que no debe copiarse. Por si acaso también, me acerco a Monty y le enseño el aviso. //"Ah, vale, vale"// - dice Monty, otra vez.
 +
 +Veinte minutos después, Monty //hace commit// y sube al repositorio su cambio. El cambio, por supuesto, lleva exactamente //"un ''<img>'' con el ''onClick'' puesto ahí directamente"//. Porque, obvio, está copiado directamente del wiki.
 +
 +Yo no tengo ningún interés de tener conflictos a estas alturas, claro, así que no le digo nada. Pero como me entra ya la duda de si a lo mejor es que es cosa mía, se lo enseño a Edward. Lo ve.
 +
 +>¿Eh? Pero, ¿qué...? Ah... ah, ya. Que ha hecho lo que le ha salido de las narices. En fin...
 +
 +Sí, "en fin". En fin, Monty [[old:ay_ay_ay_agile:hacemuchotiempo|me recuerda a alguien de hace muchos años]].
 +
 +----
 +
 +Esto es un ejemplo bastante representativo...
 +
 +En el año 2013 se crea una tarea para desarrollar en la aplicación un apartado de //Preguntas Frecuentes//.
 +
 +Diez días después, un desarrollador de aquella época sube la //propuesta// al repositorio. Es solo eso, una propuesta. Básicamente poco más que una página maquetada con media docena de preguntas de ejemplo con una respuesta que dice, literalmente: "Respuestaaaaaaaaaaaaaaa". Tiene un poco de JavaScript para desplegar las respuestas. Insisto en que se sube al repositorio. Esto significa que, automáticamente pasa a producción algún tiempo después, sin enlazar desde ningún sitio pero presente.
 +
 +Seis meses, en Febrero, después la propuesta no ha progresado. En la tarea de JIRA no hay ningún comentario en absoluto sobre la propuesta en sí. No hay nada que refleje ningún avance ni ninguna decisión. Lo único que hay es un cambio de estado, hecho en grupo a varias tareas, que simplemente dice que queda //"para versiones futuras"//.
 +
 +Para eso de las verrsiones futuras, se abre inmediatamente otra tarea en la que se //investiga// la idea de las preguntas frecuentes. Se registran unas cuantas semanas de trabajo de tres o cuatro personas a lo largo de los siguientes meses. Se sube una nueva propuesta, esta vez más completa con las preguntas ya en una tabla de base de datos, al repositorio para su evaluación.
 +
 +A final de Marzo sube el último cambio al repositorio. En Mayo, sin más comentario, la tarea se marca como resuelta. La tabla de base de datos con las preguntas está vacía. La funcionalidad está desactivada. Todo el código está presente y desplegado en producción, claro está.
 +
 +No parece haber más movimiento hasta 3 años después cuando, sin más comentario, la tarea pasa a estar //"Cerrada"// y //"Solucionada"// y al mismo tiempo se abre otra tarea nueva para dar de baja toda la funcionalidad. El motivo de dar de baja la funcionalidad es que, tras tener la funcionalidad en producción tres años, no se ha usado nunca. No se ha hecho disponible para ningún perfil, el tema "está bastante anticuado" y "posiblemente se haga la gestión de FAQ" en un portal de Sharepoint que se está planteando utilizar para varias cosas. El portal de Sharepoint llegará un par de años después.
 +
 +No se elimina nada en absoluto del código. Las tablas siguen vacías pero presentes a día de hoy en la base de datos. Se deja todo el código ahí, como un ajusticiado a la entrada de la ciudad que avisa al visitante de que lo único que va a encontrar aquí es podredumbre y muerte.
 +
 +Pero no, no, el código no queda ahí colgado fuera de la ciudad. Ni siquiera en una pila de cadáveres en un rincón. Queda, junto con docenas más, repartido por la aplicación, sin nada que lo distinga del código "bueno". Son cadáveres en las calles, vestidos y arreglados. Incluso cuidados, porque de vez en cuando se ven que alguien sin saber que están muertos, les pone bien el sombrero, les arregla un par de estilos que nunca se verán, o les cambia un par de funciones de un JavaScript que nunca se ejecuta.
 +
 +----
 +
 +Mientras espero que llegue el día oficial de dejar esto para siempre, me dedico a pensar qué único detalle técnico podría resumir todo este proyecto. Ahora mismo tengo algunos candidatos en la cabeza.
 +
 +El primero es ''ArticuloVO''. Está claro que en una aplicación de logística, que es fundamentalmente, para //gestionar artículos//, el "artículo" sería algo importante. Todo lo que se gestiona son artículos. Un blindado, una rueda, un ordenador, una silla, unas botas, una ración de comida... Todo es un artículo. Estrictamente. Vamos, que no hay diferentes tipos de artículos. Todo es un "artículo genérico". Y así, ''ArticuloVO'' tiene todas las propiedades que puede tener //cualquier artículo//. 450 propiedades en total. Una ración de comida tiene una //posición de montaje//. Unas botas tienen un //peso máximo que soportan en su cuarto eje//. ''ArticuloVO'' es una taxonomía entera de prácticamente cualquier cosa desnormalizada a una única entidad genérica... Y luego se trata con no-sé-contar-cuántas combinaciones de excepciones y casos particulares de esas propiedades. Me gusta como símbolo porque representa bien la filosofía general de toda la aplicación.
 +
 +Pero por otro lado la historia de [[old:ay_ay_ay_agile:hasta10000|hasta10000]] es tan fascinante y expresa //tan// bien la forma de desarrollar del equipo en general... Es, casi, mi historia favorita de este proyecto.
 +
 +Sin embargo, llevo varios días acordándome de estas dos líneas de código Java:
 +
 +<sxh java>
 +Long idCode = null;
 +idCode = idCode.parseLong("612");
 +</sxh>
 +
 +Porque estas dos líneas representan mucho más de lo que se ve a simple vista. Incluso más de lo que se ve después de pensar en ellas unos minutos. Hay por ahí otras líneas parecidas, como un ''parseFloat(24)'' en una página, pero quedarse en eso que se ve es muy superficial. Creo sinceramente que, si quisiera, podría llegar a dar toda una charla de más de una hora((Y hasta dos horas, si no fuera tan aburrido)) sobre esas dos líneas.
 +
 +----
 +
 +== Epílogo ==
 +
 +Finalmente me fui del proyecto -y de la empresa- hace unos días.
 +
 +No hubo grandes despedidas, pero sí algunas pequeñas. Una, quizá dos personas que seguramente son de lo poco salvable del equipo, se despidieron de mi charlando un rato. Otro par ya lo había hecho antes, porque en estos últimos días muchos han tenido que cogerse //"obligados"// los días de vacaciones que les quedaban. Del resto alguno ni siquiera sabía que me iba hasta que ha ocurrido.
 +
 +Los dos Trajes se despidieron en una charla de media hora en la que, "de muy buen rollo", me recordaron que ellos esperaban otra cosa de mi, que la vida es así, y que aunque seguían pensando que no necesitaban cambiar nada, iban a hacer algún despido //pronto//. No sé si fue la forma de decírmelo, pero me pareció algo //poco agradable// de decirme en esa situación.
 +
 +En fin, aunque sospechaba que sería él por cómo lo dijeron, hoy me ha llegado la confirmación de que han despedido a Monty. Así, sin más. No puedo decir que me alegre, porque realmente no me alegro, pero por otra parte se lo venía buscando desde hacía tiempo. En los últimos meses estuvo trabajando con supervisión directa y muy cercana de Karen. Y seguramente él no sospechaba nada, pero yo tenía la sensación de que le estaba evaluando, y que no lo estaba haciendo precisamente bien.
 +
 +Me da un poco de pena la situación en que se queda Edward. Queda como el único con la etiqueta //"front"// y con todas las papeletas para que le caiga encima un montón de porquería. No creo que tarde mucho en buscarse otra cosa, y cuando eso pase... bueno, supongo que el equipo quedará como estaba antes de que entráramos nosotros tres. Solo Gunther, el especialista en datos, sigue como fichaje reciente. El resto... un montón de ruinas en un equilibrio inestable de peleas y gritos.
 +
 +Queda solo una cosa... En algún momento me llegué a preguntar si quizá perderían el contrato. El concurso era en estos meses con la adjudicación a partir de Febrero de 2021. Y me preguntaba esto porque, bueno, la empresa había perdido recientemente la renovación de un contrato similar. Pero por simple curiosidad (y por un poco de casualidad) me encontré leyendo por encima el pliego de requerimientos y condiciones del concurso de mantenimiento y resulta que está escrito con la colaboración del Traje y del Arquitecto. No tengo pruebas, obviamente, pero tampoco tengo dudas. El pliego incluye detalles técnicos que no tendría porqué incluir y que son reflejo directo de lo que el Traje y el Arquitecto quieren hacer. Sí, ya, eso sería ligéramente sucio. Solo son 6 millones y pico de euros que pagamos entre todos. 6 millones para mantener las tonterías del Arquitecto desde su casa... En fin... Sí, se lo han renovado, claro.