Diario de Programación

Siguiendo con el tema de la planificación me encuentro con más problemas, de esos que en la teoría no salen.

Como he comentado muchas veces, tenemos muchos proyectos, similares y todos solapados en el tiempo. Algunos están finalizando, otros están a mitad de desarrollo y otros están comenzando, preparando prototipos/demos para que los clientes se hagan una idea de lo que van a tener, pero ya configurado para ellos.

Como todos los proyectos son similares, se hacen librerías compartidas y los programadores se especializan en temas. Sería poco eficiente hacer grupos separados por proyectos sin que compartan nada, sin librerías comunes, sin conocimientos reaprovechados.

Y esto prepara dos problemas grandes:

1. Algunos programadores están en las tres fases de los proyectos a la vez. Están manteniendo/depurando su especialidad en los proyectos que están acabando, están desarrollando en medio de otro proyecto y tienen que preparar la demo de su especialidad en un tercer proyecto. Además, los programadores que se encuentran en estos problemas, son precisamente programadores experimentados (han participado en proyectos de dos o tres años que están acabando) y se les carga adicionalmente con la enseñanza de los programadores nuevos.
2. Las librerías comunes siempre están congeladas. Los proyectos que están finalizando no nos permiten grandes cambios en estas librerías. Los proyectos en desarrollo nos piden cambios en ellas y los nuevos proyectos piden a gritos grandes refactorizaciones y replanteamientos de esas librerías. Supongo que nada que no se pueda arreglar con unas ramas de CVS.

y cito en concreto mi caso

1. Incidencias y mejoras pendientes en proyectos casi acabados. O corrijo yo el código o se lo suelto a un novato. Si se lo suelto a un novato, perderé más tiempo en explicarle qué tocar y dónde tocar que en tocarlo yo mismo. Si no se lo suelto, me quedo yo con eso hasta el final.
2. Proyectos en desarrollo, con ganas locas de meterme a codificar algo en ellos, pero totalmente imposibilitado por falta de tiempo. Me refiero a un tiempo relativamente largo en el que pueda programar algo de cierto tamaño todo seguido.
3. Proyectos nuevos, en los que llevo programadores nuevos, especificando y dando algunos esquemas UML de alto nivel para seguir una arquitectura uniforme en todos los módulos. Encima, algunos de los nuevos están en la software factory, en otra ciudad.

Y mi día laboral consiste en

1. Abrir el correo y rezar para que no haya muchos marrones ese día.
2. Atender marrones, gente y reuniones que me vienen antes de que haya acabado de leer el correo
3. Así hasta la hora de comer. Después de comer, si regreso antes que los demás (suele ser el caso), sigo leyendo el correo de por la mañana
4. Más gente, más reuniones y más marrones
5. Me voy a casa con la sensación (y la certeza real) de que no he hecho nada en todo el día y de que lo que tenía planificado lleva exactamente un día de retraso más que ayer.

En fin, últimamente programo más en casa en ratos libres que en el trabajo. Y todavía no acabo de entender cómo tanta charla, tanta reunión y tanto documentito pueden hacer que la cosa vaya más rápida que si yo me pongo a programar como uno más.

Cada vez estoy más escéptico con el tema de la planificación de proyectos. No me refiero a hacerla, revisarla periódicamente, rehacerla, que es "relativamente sencillo" (ni de coña, hace falta mucha disciplina y experiencia). Me refiero a hacer una planificación que luego se cumpla.

Quizás gente con experiencia en planificaciones puede planificar más o menos correctamente un proyecto que dure unos meses y con unos pocos programadores (dos, tres, quizás cuatro). Pero, en nuestro caso, estamos hablando de varios proyectos con funcionalidades similares, pero lo suficientemente distintas como para requerir modificaciones, todos en paralelo, con alrededor de treinta programadores en total y plazos de entrega de uno a tres años.

Cualquier cosa que leas de planificación que te dice que hagas tareas muy granulares, del orden de tiempo estimado de uno o dos días por tarea. Si echamos unas cuentas, treinta programadores durante dos años, con tareas de 1 día, son aproximadamente …. ¡¡Buff, ni me atrevo a calcularlo!!.

Obviamente, no se puede calcular a priori todas esas tareas. La solución supuestamente es fijar pequeñas entregas cada uno o dos meses, dividir a la gente en grupos y planificar las tareas para esos dos o tres meses. Estupendo. ¿Y el resto del proyecto? ¿Y las demás entregas?. Por supuesto, todas ellas están fatalmente planificadas, porque ni se han detallado lo suficiente, ni se tiene muy claro que es lo que se tiene que hacer. ¿De qué sirve tener perfectamente planificado el primer mes o reajustar la planificación del primer mes si no se sabe nada fiable del resto del proyecto?

Al final da la impresión de que lo que hay que hacer es tener claro qué cosas son importantes y dedicarse a ellas primero, dejando lo secundario para el final por si da tiempo. Al final es algo así como "estará lo que dé tiempo a hacer en plazo y el resto no se hace", por lo que efectivamente es importante hacer lo más importante primero para que al menos eso esté. Pero ninguna planificación nos dirá a priori cuántas de esas cosas van a estar hasta que estemos ya muy cerca del final.

Quizás hay que dividir el plazo total entre las funcionalidades a implementar y hacer entregas cada uno o dos meses con esas funcionalidades. Pero para que se cumpla el plazo total, va a haber que pasado el tiempo de la primera entrega, dejar las funcionalidades que entren en ella como estén y pasar al segundo grupo. Por supuesto, en cada momento habrá que decidir si se continúa con las que no se han acabado (a costa de quitar otras) o se dejan como están para seguir con las siguientes. En cualquier caso, NO es una planificación para que se cumpla, sino es más que nada saber cómo se va para asumir el retraso y quitar cosas.

Cada vez estoy más decepcionado con este tipo de cosas.

Estos días atrás, en varias reuniones con mi jefa, ha salido varias veces el mismo tema. El problema es que los dos o tres del departamento que tienen fama de saber mucho java, mucha orientación a objetos, mucho de patrones de diseño y de ser los que mejor programan, hacen un código que los compañeros no entienden fácilmente. Y efectivamente es así. El código que hacen esas personas también tiene fama de ser muy dificil de seguir, mantener o modificar por otras personas que no sean ellos mismos.

Hay otros compañeros, sin embargo, que no saben tanto de orientación a objetos o de patrones de diseño, pero su código es más simple y más fácil de entender, pero muchísimo menos reutilizable.

¿Cual es el motivo?. Le he estado dando vueltas y me hace la impresión que es algo similar a lo que comenté en el post anterior de que programar es como escribir.

Quitando a los que comenten faltas de ortografía, hay quien se centra en el problema concreto que tiene y con un código "lineal", con un mínimo de orientación a objetos y un mínimo de patrones de diseño, resuelve eficientemente el problema, de una forma rápida. Ese código funciona bien, se hacen unas pocas clases sencillas, pero grandes y, por ello, es fácil de entender: va todo seguido y no hay que rebuscar entre varias clases, interfaces y polimorfismos variados para ver qué hace. Está todo ahí y se ve. Pero esas clases sólo sirven para eso y no se pueden usar en más sitios. Esto sería el equivalente a escribir en prosa con una prosa eficiente.

Otros, menos prácticos pero con más conocimientos, para resolver el mismo problema, montan toda una estructura de clases e interfaces. Posiblemente el diseño de estas clases es mucho más orientado a objetos y más elegante desde ese punto de vista que en el caso anterior. Algunas de esas clases son lo suficientemente generales como para usarlas en otros sitios. Sin embargo, tardan más en hacer el código y hay menos gente capaz de entenderlo sin leerse previamente un buen manual del diseño del mismo, incluso aunque sean gente con profundos conocimientos de OO y patrones. Esto sería el equivalente a escribir poesía, donde se da especial importancia al cómo se cuentan las cosas.

Llega el tiempo de hacer modificaciones por la misma persona que ha hecho el código. En general, cualquier modificación se hace más rápido en el segundo caso, en el de la orientación a objetos, si hay un buen diseño.  Sin embargo, hay veces que esta modificación cuesta mucho más en este segundo caso. ¿Por qué? Nuevamente por el tema de darle demasiada importancia a la forma. A veces la modificación que se pide se hace fácilmente añadiendo una dependencia de una cosa totalmente extraña a nuestro diseño (un dato que no tiene nada que ver, una clase que es muy especifica del proyecto, etc). Para la primera persona en cuya cabeza está el resolver el problema lo antes posible, añadir esa dependencia no le cuesta nada, la pone y ya está. Sin embargo, para la segunda persona, añadir esa dependencia le supone un trauma de concepto. Se niega a ponerla puesto que ese dato no pega nada ahí y tiene que rehacer el diseño para contemplar esta nueva posibilidad de una forma elegante con el conjunto. Lo que a la primera persona le puede costar diez minutos "ñapear", a la segunda le puede costar un par de días.

Y al final llega la gran cuestión. ¿eficacia o elegancia?. ¿No estará justificado ñapear de vez en cuando para conseguir un código más simple en apariencia o cumplir plazos?. Supongo que como siempre, en el punto medio está la virtud. No hacer ñapas sangrantes, pero tampoco ser demasiado puristas con la orientación a objetos. Y me hace la impresión que esto es lo que ha llevado a los gurus a una de las bases de las metodologías ágiles y a cosas como el TDD. Si nos fijamos, en estas metodologías suelen ser comunes cosas como "resuelve tu problema lo más rápido y de la forma más sencilla posible", no hagas cosas generales "por si en un futuro las usas". Hay que centrarse en y resolver el problema de ahora. El del futuro hay que resolverlo cuando se presente haciendo refactoring si es necesario. El diseño se debe ir haciendo justo antes de programar y sólo para resolver el problema concreto del momento.

Cada vez estoy más convencido de que aprender un lenguaje de programación es fácil, pero aprender a programar puede llevar toda una vida.

El otro día nos hicieron una auditoría interna de software. Como era de software, me soltaron a mí al auditor. Le duré menos de cinco minutos.

El auditor empezó su ristra de preguntas, que básicamente consistía en de los dos mil documentos que teóricamente pueden hacerse (requisitos, plan de desarrollo, diseño preliminar, manual de usuario, de instalación, de árbol de configuración, …), preguntarme uno por uno si lo hacíamos. Yo me dedico a codificar software y algunos de esos documentos sí me suenan, o bien porque me llegan, o bien porque incluso colaboro en ellos, pero del resto ni idea, ni si se hacen, ni cual es el proceso para hacerlos e incluso muchos de ellos, nombrados por sus siglas, los había oido por primera vez. De hecho, en la lista anterior he puesto algunos de los que sí conozco, porque de los otros mil novecientos ni siquiera me acuerdo ahora del nombre.

Cuando llegó el momento en que nos acercamos al tema de software real, vi llegar mi oportunidad, pero al auditor le importaba tres pepinos qué herramientas usábamos (cruise control, bugzilla, test de junit, etc). Unicamente hablamos de que usabamos CVS y hacíamos ramas de vez en cuando. Realmente lo que le interesaba era saber si teníamos controladas las versiones del proyecto completo y si teníamos algún documento que reflejara todas las mejoras y peoras de una versión respecto a la anterior. Asi que de software nada de nada, lo único de interes es que usamos CVS.

Cada vez me da más pena este mundo empresarial, en el que lo importante son las apariencias y no la realidad, en donde lo realmente importante del softwre son los documentos que le acompañan, y no el software en sí mismo. El software puede ser una patata, pero si va acompañado de varios documetnos tamaño "El Quijote", está bien hecho. Y si tienes todos esos documentos, aunque el software no vaya, cumplirás con las normas de calidad ISO 9001 y similares. Luego, claro, se sacan premios a la "excelencia empresarial" (nombrecito, ¿de dónde lo habrán sacado?).

Como comenté cuando puse los resultados de mi última planificación con XPlanner, uno de mis propósitos de año nuevo es aprender a planificar.

La semana pasada fué de trabajo, pero me la tomé como una toma de contacto. Entre que iba llegando la gente y me ponía al día, sobre todo despejándome la pereza de encima, no planifiqué nada y me dediqué a pequeños arreglos sueltos que siempre hay que hacer.

Hoy, sin embargo, me he puesto un poco más en serio. He hecho una pequeña planificación con XPlanner para esta semana, detallando lo más posible y poniendo el tiempo de las tareas en horas. Además, he planificado sólo unas treinta horas, porque supongo que perderé el tiempo miserablemente en algún momento, como todo hijo de vecino. He echado una media hora larga en planificar esas tareas.

De momento hoy bien, he hecho unas seis horas de las tareas planificadas y he acabado dos de ellas. El Lunes pondré el gráfico con la planificación, a ver que ha salido. De todas formas, he visto una tarea que se me ha olvidado meter y tendré que meter….

Hace un par de meses acudí a una especie de jornadas tecnológicas con compañeros de la empresa, pero que trabajan en otros centros de trabajo -en otras ciudades- y hacen cosas distintas a las nuestras. Lo de siempre, un poco por conocernos, saber qué cosas hacemos unos y otros y ver qué cosas podemos aprovechar unos de otros.

Me llamó muchísimo la atención uno de ellos, que comentaba que en su departamento, también dedicado a hacer software, han decidido que todas las prácticas de programación no valen absolutamente para nada. Han decidido que en cuanto se puede hay que empezar a programar, probar mucho y solucionar las cosas de la forma más directa y rápida posible. Diseño cero, copy paste el necesario, librerías si son muy evidentes o no llevan mucho tiempo, muchas pruebas y pa´lante.

Lo cierto es que hay muchísimas veces que apetece hacer eso y que piensas que es la única opción buena. Es lo que piensas cuando haces diseño y ves que luego, por dejadez o por no pensarlo bien, no se sigue. Siempre mientras haces el código ves cosas que no habías pensado en el diseño. También es lo que pasa cuando ves que gente que no sigue las mismas prácticas que tú tarda menos en hacer su trabajo, precisamente porque no piensa en extraer código común. Y sobre todo cuando ves que eres mucho más feliz programando directamente, sin comerte demasiado el coco con software super-elegante con miles de test unitarios.

Sin embargo, pienso que se llega a esas conclusiones tras un análisis superficial. A las librerías comunes les sacas provecho, y mucho, en los siguientes proyectos, incluso aunque tengas que ampliarlas y mejorarlas. Y sobre todo, en tiempo de integración y pruebas. Código con test unitarios basado en librerías ya probadas funciona comienza a funcionar mucho más rápido y mejor que código hecho de nuevas o con copy-paste.

Lo de que el diseño y las buenas prácticas no sirven, es a la conclusión que se llega cuando no se sabe hacer bien. Y a la primera nadie lo hace bien, hay que insistir varios proyectos y aprender de tus errores. En los primeros proyectos con test unitarios, se tarda mucho en hacer los test y no son los test que se deberían hacer, por lo que no sirven para encontrar errores. Con la experiencia aprendes qué test son los que merece la pena hacer y cómo hacerlos. Con el diseño pasa lo mismo, nuestros primeros diseños no valen para nada, con el tiempo aprendes qué es lo que debes plasmar en papel antes de codificar. Y así un largo etcétera de buenas costumbres.

Yo por mi parte, y como mencioné en posts anteriores, sigo empeñado en conseguir lanzar un Scrum en condiciones y en aprender a planificar. Estoy seguro que mis fracasos en ambas cosas son por falta de experiencia y seguiré insistiendo.

Llevo un par de semanas trabajando con XPlanner.  En él pones las tareas que vas a realizar y la estimación de tiempos de cada una de ellas. Día a día vas poniendo el tiempo que has trabajado en ellas y para ver cómo vas te saca unos gráficos. En el eje horizontal pone los días. En el eje vertical pone las horas estimadas de trabajo y las horas trabajadas.

En la situación ideal, las horas estimadas deberían ser una línea perfectamente horizontal, es decir, has sido capaz de estimar a priori todo lo que tienes que hacer y el tiempo que te va a llevar. El gráfico de horas trabajadas debería ser una línea que empiza en cero y día a día va subiendo hasta, al final del periodo estimado -una semana en mi caso- alcanza a la línea de horas estimadas. Justo en el momento de alcanzar a la de horas estimadas, el trabajo, si todo se ha planificado bien, debería estar terminado.

Pues bien, eso es la situación teórica. Ahí va mi gráfico de esta semana pasada

Ante todo, se puede ver que no tengo ni repajolera idea de planificación. El Lunes no hice absolutamente nada de lo planificado, salvo quizás hacer la planificación, pero que no está planificada la tarea de hacer la planificación. El Martes, Miércoles y Jueves sí hice algo, pero casi todo lo que hacía eran tareas nuevas necesarias que no había previsto. Por eso la curva roja de tiempo previsto, en vez de ser horizontal, va subiendo. El Viernes fue el día que capture el gráfico y por eso no hay todavía datos -por cierto, se me olvidó apuntar el tiempo trabajado al final de la jornada-. Al final, dos conclusiones:

• No he sido capaz de prever las tareas. Cada vez que me meto en ellas, me aparecen tareas previas que hay que hacer y no había previsto.
• El tiempo de trabajo a la semana en lo planificado es más bien escaso. Tengo muchas interrupciones que me ocupan tiempo en cosas que no son de esta guerra. Como excusa, es la semana previa a navidades y tenemos muchos jolgorios asociados.

En fin, lo más importante es no desanimarse y persistir. Como propósito de año nuevo -junto con los consabidos hacer algo de deporte, ponerse a dieta y dejar de fumar-, me pondré el de aprender a planificar.

Por cierto, este es el típico gráfico de Scrum para ver como va el Sprint.

Ando últimamente un poco preocupado. Supuestamente debo dedicarme a diseñar código y otros lo codificarán. El problema principal que veo es que hay mucha distancia desde el punto de vista teórico del diseño y "las trincheras" de la codificación.

Me explico.

Cuando haces diseño, sobre todo de grandes aplicaciones, no puedes meterte en los detalles del código. Puedes pensar una arquitectura, unos módulos, las responsabilidades de los modulos y las interfaces de los mismos. La implementación de dichas interfaces no puedes meterte en ellas, ya que ni eres capaz de prever a priori todo lo que hay que hacer, ni sabes los problemas de codificación que van a surgir.

Ahora llevo unos días codificando sobre código ya hecho y más o menos pensado por mi, pero codificado por otros. Estoy haciendo código nuevo aprovechando ese código ya existente. Y es complicado. A pesar de que más o menos había ideado yo la esctructura de todo eso, y más o menos la sigue, veo que los problemas que se encontraron al codificarlo los han ido resolviendo como han podido, unos mejor que otros. Veo que ese código, que teóricamente debería poder reutilizar tal cual, no me vale tal cual. Tengo que hacer cambios -no muy grandes, pero sí cambios-. La culpa es en parte mía, porque mi diseño inicial era válido para los proyectos que había en curso, pero no lo bastante como para estos nuevos. También es en parte culpa de los codificadores. Posiblemente movidos por la prisa que siempre les meten los jefes, muchas veces optaron por las soluciones rápidas en vez de las buenas.

Sobre todo veo código repetido, cosas que deberían ser comunes, que yo no había previsto como comunes y que los programadores, movidos por las prisas, acaban rápidamente con copy-paste. Y ahora me veo obligado a hacer yo también otro copy-paste de ese trozo para el nuevo proyecto -nuevamente movido por las prisas- o bien "refactorizar" -ignorando las prisas-. Tocar el código hecho, llevarme esas copias a un sitio común y probar que todo sigue funcionando -los test unitarios brillan por su ausencia-.

Todo esto me lleva a pensar que es muy difícil conseguir un diseño bueno a priori y que es realmente difícil conseguir que se siga. El diseñador debe estar muy metido en el día a día del código para ver lo que se está haciendo, lo cual hace imposible que pueda abarcar aplicaciones demasiado grandes. Metiéndose en el día a día, puede controlar el diseño de trozos relativamente pequeños.

Cada vez estoy más convencido de que las estructuras jerárquicas, en que uno hace arquitectura, otros hacen diseño detallado y otros codifican no llevan realmente a ningún sitio. Es mucho mejor un grupo de gente con mucha comunicación, que hagan un diseño previo y, sobre todo, que todos ellos sean programadores hábiles, a los que les guste programar y tengan muchísimo interés en hacer el código bien… ¡¡ y que no les metan prisa !!.

En software, hay veces que en la teoría hay unas pequeñas ideas que son muy sencillas, pero que luego, a la hora de la realidad y del trabajo día a día son realmente complejas. Ya me he topado en varias ocasiones con ellas y he visto como caigo una y otra vez en los mismos problemas que teóricamente sé y no debería caer en ellos. Pongo unos cuantos ejemplos.

El primero y más tonto, es a la hora de  hacer componentes reutilizables. Tienes, por ejemplo, que hacer un gráfico que en el eje de las x pinte el tiempo y en el eje de las y el número de veces que te llega un mensaje por un socket. Cuando te pones a codificar ves que es un simple histograma, o un gráfico x/y en el que hay una función, y decides hacerlo general. Te haces un proyecto separado de gráfico-histograma, lo codificas y lo haces general. Es capaz de dibujar cualquier función por puntos o histograma. Curiosamente para pasarle las x has llamado al método setFechaHora() y setNumeroMesajes().

Sin embargo, hacer ese ejemplo bien, también es complejo. En cierta ocasión quise hacer una especie de traductor de palabras de inglés a español. Hice un fichero de propiedades con palabra_español=palabra_ingles. Me empece a hacer la clase que leía el fichero de propiedades y ponerle método getEnInglés(), getEnEspañol(), etc. Al final me doy cuenta que es más general que todo eso, puede servir para cualquier pareja de idiomas. Así que getEnIdioma1() y getEnIdioma2(). Pero claro, es más general todavía, sirve para cualquier pareja clave-valor. Vuelvo a cambiar los métodos… y al final tengo una copia hecha por mi mismo de la clase Properties de java.

Es difícil saber hasta dónde generalizar y hasta dónde dejar como específico.

Segundo ejemplo de cosa sencilla compleja. Actualmente estoy usando XPlanner, un poco para jugar, pero tratando de tomármelo un poco en serio. Tengo muy clara la idea que hay que pensar una historia de usuario -alguna funcionalidad concreta- y ponerle tareas concretas con tiempos y demás. El problema que tengo es que siempre acabo poniendo tareas generales que no son de una funcionalidad concreta. Por ejemplo, las historias deberían ser "dar de alta usuario nuevo", "borrar usuario existente", "modificar datos de usuario", etc. Las tareas deberían ser "hacer la gui de pedir usuario nuevo"; "hacer la inserción de usuario nuevo en bd", etc. Sin embargo, tiendo a poner "gestión de usuarios de la bd", en la que incluyo alta, baja y modificación de usuario con la base de datos. Supongo que el mal es excusable en el sentido de que tratas de hacer todo lo relativo a base de datos de una sola vez. Sin embargo, aunque quieras aprovechar a hacerlo todo de golpe, eso no quita que pongas TRES tareas separadas: alta, baja y modificación de usuario. Esto, además, debe ser así, porque obliga a pensar qué es exactamente eso de "gestión de usuarios en la bd". Independientemente de que se use o no XPlanner, este es un problema demasiado habitual en cualquier tipo de planificación: no definir claramente cual es la tarea exacta que se quiere hacer.

Es difícil concretar lo suficiente las tareas a hacer.

En cuanto al tercer ejemplo, el consabido Scrum que ya he comentado varias veces. Lees la teoría y es algo muy sencillo. Sin embargo, la práctica es bastante compleja. Requiere mucha, mucha disciplina, para hacer las reuniones diarias. Se junta con el problema que comenté antes de XPlanner/planificación: los sprint deberían ser concretos y no cosas como "gestionar usuarios en la bd". Y lo que yo veo más complejo, requiere gente que colabore y con buen rollo. Hace falta motivar a la gente, que vayan a priori convencidos de que el método es útil e intenten sacarlo adelante. De nada sirve que creas tú solo en él, andes todos los días tirando de la gente para las reuniones y el día que faltas nadie mueva un dedo por seguir con el tema.

Es dificil organizar a más de uno -incluso yo conmigo mismo tengo mis problemas-.

Este comentario de checksum me lleva a explicar un poco más la situación en mi empresa, en concreto, mi situación, tanto la teórica como la real.

Los hechos:

A mi jefa de toda la vida la han ascendido. Ahora lleva a la friolera de 30 personas. Sin embargo, ella no es responsable de los proyectos. Los responsables de los proyectos son personas ajenas a su grupo y ella tiene que asignar su gente a los proyectos, para que los vayan haciendo. Vaya, como una "software factory" interna. Su responsabilidad es que toda la gente tenga trabajo y que trabajen de una forma uniforme, reaprovechando código entre proyectos y formas de hacer las cosas comunes a todos los proyectos. Dicho en otras palabras, que cada proyecto no sea de su padre y de su madre.

La Idealidad:

Mi jefa, con toda su buena intención, pretende organizar a esa gente para que trabajen de forma adecuada, según las buenas costumbres de programación, diseños, especificaciones, sin repetir código de un proyecto a otro, test unitarios, usen las mismas herramientas, etc, etc.

Para ello y puesto que llevamos mucho tiempo trabajando juntos y sabe que a mi me gustan todos esos temas, me ha dejado fuera de los proyectos. No estoy asignado a ninguno y pretende que la ayude a alcanzar esa organización ideal.

La cruda realidad:

Mi jefa anda más liada que la pata de un romano con cosas ajenas a su grupo de gente -herencias de su cargo anterior-, así que tiempo para organizar cero patatero. Yo, al no estar asignado a ningún proyecto, soy el que queda libre, por lo que cuando hay algo de lo que nadie puede -o quiere- ocuparse, me toca a mí. Así, sigo codificando, pero no código nuevo, sino código huérfano, realizado en su día por gente que se ha cambiado de departamento o ido de la empresa.

En cuanto a organizar, por el motivo anterior tengo poco tiempo, y además, como sigo siendo un don nadie currito de decimotercera clase, lo único que puedo hacer es aconsejar a la gente formas de hacer las cosas: "haz test automáticos", "haz un diseño y mételo en la wiki", "vamos a usar maven y javahelp", "usa esta herramienta", etc, etc. En algunos campos obtengo pequeñas victorias y en otros grandes fustraciones. Ente la gente a la que aconsejo hay varias especies, cada uno de su padre y de su madre:

• Los mios. Los dos o tres que me hacen caso incondicionalmente o, al menos, se toman en serio lo que digo y lo intentan. De treinta, dos o tres es una "buena proporción".
• Los nuevos. Hacen lo que les dices normalmente sin rechistar. A los que pillo yo o los que pillan los mios, siguen los consejos. Los que caen en manos ajenas, hacen lo que les dicen sus jefes ajenos.
• Los amables. Me escuchan, me dicen que tengo razón, que sí es bueno lo que digo… y luego no hacen ni puto caso. Siguen como siempre.
• Los pasotas. Ni escuchan. Oyen cosas como "patrón de diseño", les da el bostezo, se duermen y cuando acabas tu discurso les despiertas para que sigan con su trabajo.
• Los contrarios. Te escuchan, te argumentan en contra y siguen haciendo lo que les da la gana.
• Los de la programación heroica. Todo lo que digo son tonterías, los test unitarios es perder el tiempo, las ramas de CVS son muy complicadas, incluso CVS es muy complicado, maven es un lio, el diseño no sirve para nada. Lo que hay que hacer es ponerse a codificar ya, si es posible haciendo copy-paste de un proyecto anterior, y luego probar mucho, mucho, mucho.

Así que nada, en eso estamos. Y además, viendo que las "software factories" externas son cada vez una realidad más real y que cada vez somos menos gente, te entra la duda de si merece siquiera la pena intentar cualquier cosa de organizar nada. Dentro de cuatro días igual no hacemos software nosotros y lo de maven y los test unitarios nos quedará un poco lejos.