Apr 30

Pequeño éxito … ¡Y más trabajo!

Como comenté hace unos días, terminé mi pequeña aplicación en python que permite recoger de la gente los tiempos que han dedicado a cada uno de los proyectos y luego genera automáticamente un Excel para entregar al encargado de guardar todo esto oportunamente.

Pues bien, esa aplicación tonta ahorra a mi jefa un trabajo de un par de días de andar preguntando a cada uno a qué se ha dedicado y generar el excel a mano, así que le ha encantado. Tanto, que ha empezado a comentárselo a los demás jefes con el mismo problema y también les ha encantado. ¡¡ Todos quieren !!.

Y claro, cada uno quiere mejoras, añadidos y cosas variadas. Lo que era una aplicación cutre, que básicamente es un script capaz de admitir los datos de la gente desde el navegador y generar un excel, tiene pinta de que se va a convertir con el tiempo en una señora aplicación.

Los jefes que tienen gente, quieren usarla, así que en principio les vale tal cual. La única pega es que cada uno luego querrá el excel de su gente en concreto y no un excel general con todos. Eso me hará meter una nueva columna en la tabla "gente", para indicar quién es su jefe. Y me obligará en la parte de obtener resultados a poner un pequeño combobox que diga "elige al jefe cuya gente quieres convertir en excel".

Por otra parte, están los jefes responsables de los proyectos, con poca gente a su cargo, pero si con un proyecto con muchas contraseñas y muchos dineros. Para ellos el excel es lo de menos, pero lo que si están pidiendo es que quieren una forma de ver cuánta gente carga a su proyecto e incluso un histórico, para saber en cada una de las contraseñas del proyecto, cuánto llevan gastado. Tendré que poner una nueva consulta en la que seleccionando un proyecto salga un listado de toda la gente que se ha dedicado a él.

En fin, tiene pinta de que va a ir creciendo. Lo que generaba un excel con unas veintitantas personas dedicadas a unos siete u otro proyectos, van a ser ahora cerca de sesenta personas dedicadas a una veintena de proyectos. Lo que era una consulta simple, se va a convertir en un par de consultas con cláusula where pedida desde la web.

Y hablando de pequeños éxitos por tareas hechas de motu propio. Hace ya un par de años se me ocurrió que una wiki podía ser buena idea y la instalé. Dentro del departamento se va usando, como siempre, unos pocos más que otros muchos. Pero el caso es que se ha ido corriendo la voz por la empresa. El otro día tuve que mostrarle la wiki a uno de los jefazos (cosa que ha sido bastante comentada entre mis compañeros con su parte de coña ;-) ). Parece que quieren poner una a nivel de la empresa.

Todo esto me recuerda mucho al artículo que leí de Joel Spolsky "Logrando resultados cuande se es un peón". Cuando ves una necesidad que tus jefes no resuelven, una buena opción es perder un poco de tiempo en resolverla tú y si se hace bien, se acaba aceptando por todos. También me da un poco de pena comprobar que muchos de los problemas se resuelven o algunas cosas salen adelante porque algún "currito" tiene la iniciativa de resolver el problema o tirar del carro, sin que nadie se lo pida y sin que ningún jefe, teóricamente responsable del tema, tome cartas en el asunto y organice o apoye la iniciativa desde el principio (y, por supuesto, ponga los medios).

Apr 23

Python: Una de cal y una de arena

Sé que "una de cal y una de arena" significa una cosa buena y una cosa mala. El problema es que nunca he sabido si la cal es la mala, la arena la buena o a la viceinversa.

Hace tiempo comenté que iba a hacer una pequeña aplicación web en python para pedirle a la gente que metiera cada mes el tiempo que dedica a cada uno de los proyectos, de forma que luego sacara en excel una tabla con dichos tiempos. Pues bien, ya está hecha (un poco de aquella manera) y funcionando. Así que tras esta mínima experiencia con python, ahí van un par de impresiones, una buena y otra mala, una de cal y otra de arena.

La cosa mala: Me da la impresión, al igual que casi todos los lenguajes de script en los que defines las cosas sobre la marcha, que python es un lenguaje muy difícil de mantener. Al no definirse claramente los tipos, cuando en una función o método recibes parámetros, no tienes ni idea de lo que recibes, salvo que lo pongas muy bien comentado. De hecho, en eclipse con el plugin pydev para programar en python, el autocompletar que te muestra los nombres de atributos y métodos de las clases, eclipse sólo te puede mostrar aquellos atributos y clases que hayas usado previamente en el código.

En java, por ejemplo, hay que declararlo todo, por lo que en cualquier momento sabes cada variable de qué tipo es y qué cosas tiene o a las que puedes llamar. No dependes (salvo para entenderlo mejor) de que el programador se haya acordado de comentar adecuadamente el código.

La cosa buena: Precisamente esta falta de tipado y el poder meter una manzana donde se espera un higo me da la impresión que hace de python un lenguaje muy flexible, y pongo un ejemplo. Puesto que mi aplicación es web, en casi todos los métodos/funciones que he hecho recibo de parámetro un Request Object, que el mismo servidor web se encarga de pasarme y con el que tengo acceso a los parámetros de la petición http, con el que puedo escribir los tag html que se verán en el navegador, etc. Pues bien, para mis pruebas sin servidor web desde eclipse, me hice una clase MiClase con un método write() similar al de Request Object, lo instancié y llamé a mis métodos a pelo pasándoles una instancia de MiClase. El código "tragó" con eso perfectamente, y la salida html salía por donde decía MiClase, es decir, por pantalla normal.

En otros lenguajes como java habría sido necesario heredar del objeto en cuestión y sobreescribir los métodos necesarios, quizás incluso declarar un constructor obligatorio con los parámetros raros que tuviera la clase padre. En java es aconsejable el uso de interfaces precisamente por este motivo, para poder cambiar una cosa por otra sin "cargar" con la clase original heredando de ella. En python no hacen falta interfaces. Basta con que la clase sustituta tenga los métodos que se usen de la clase original.

Todo esto me hace preguntarme si lo del desarrollo rápido de lenguajes como python se refiere a que no es necesario declarar los tipos (desde luego, eso ahorra tiempo, pero me parece un tiempo mínimo respecto a todo el proceso o el tiempo que puedes perder en depuración mientras decides si una variable es de un tipo u otro), o bien se debe a esta flexibilidad del lenguaje, que permite mezclar churras con merinas y todo funciona como debe.

Apr 14

Porque no soy de agobiarme…

No me agobio porque no soy de los que se agobia, pero debería agobiarme con la situación que hay.

Me acaban de poner a llevar un grupo de gente de software que colabora en muchos proyectos y me encuentro con:

  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Un montón de código recién hecho, sin probar y que no es lo suficientemente bueno como para aprovecharlo en otros proyectos sin unas grandes dosis de refactorización.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Otro montón de código hecho de hace tiempo, probado, pero que tiene muchos parches poco elegantes por encima y que se hace duro de usar para alguien que no lo conoce.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Un montón de gente nueva con los conocimientos justos de java y escasos de los sistemas que hacen.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer
  • Otro montón de gente nueva en la software factory, de los que no sé siquiera si saben java (algunos me consta que sí lo saben), pero desde luego, no conocen nuestros sistemas NADA.
  • y finalmente, un montón de jefes de proyecto que quieren todo ya, para ayer.

Pues eso, que no me agobio porque no soy de agobiarme y como leí en cierto sitio, "si todo es importante, es que nada lo es".

Apr 10

Visita a la software factory

Hoy me ha tocado visita (la primera que hago) a la software factory. Madrugón para coger el tren (la software factory está en otra ciudad) y luego, toda la mañana, una charla en la que nos contaron como es su proceso de desarrollo de software según el CMMI-3.

Una frase que me llamó la atención. Tienen un departamento que se encarga de revisar en los proyectos que "se hace lo que han dicho que van a hacer". Cuando empieza un proyecto hacen un plan de desarrollo, en el que deciden qué métricas van a pasar, qué procesos van a seguir, que pruebas, etc, etc, etc. No importa cuales decidan (dentro de un orden), pero las que digan que van a hacer, deben hacerlas.

Y otra cosa que me ha resultado realmente interesante. Tiene, por supuesto, su departamento de calidad, encargado de ver que en el plan de desarrollo del proyecto se deciden unos procesos adecuados a la envergadura del proyecto. Pero, lo más interesante de todo, es que también tienen un grupo de gente, todos ellos técnicos con experiencia y gurús a los que consultar las cosas, totalmente independiente de los proyectos y que son los realmente encargados de verificar que en en el proyecto se siguen todas las pautas decididas al principio y de que el software está bien hecho. Esto, bien pensado, es totalmente lógico. Si a un proyecto se le exige una base de datos bien diseñada, coherencia en los modelos de datos, que la interface de usuario sea uniforme, que se van a usar determinados componentes comunes, etc, los más cualificados para verificar que eso se cumple es gente experta en esos temas. Incluso son los que aconsejan a los proyectos sobre cómo realizar las cosas para cumplir con todo y tener menos trabajo.

Creo que tenemos bastante que aprender de ellos.

En cuanto a la tarde, una visita a la gente que está desarrollando en los proyectos que controlo un poco, para resolver dudas, explicar un poco más lo que tienen que hacer, etc. Como siempre, hemos encargado el trabajo sin hacer una documentación previa medianamente decente.

Apr 09

Día provechoso, día feliz

Ayer andaba un poco "depre" por los problemas del trabajo y de ahí el post. Hoy sin embargo he tenido un día tranquilo. No ha venido casi nadie a incordiarme, así que me puse a codificar. Cogí tres cosas que tenía pendientes y pude terminarlas, sin graves problemas.

Es curiosa la sensación con la que me he ido a casa. Ayer, al andar de reuniones de planificación, seguimiento, definición de cosas … se instalaron en mi mente todos los problemas aún sin solucionar que quedan pendientes. Ando ya algo curtido es esos temas, así que no me agobio, pero sí me voy a casa con ellos en la cabeza, pensativo y llego cansado, sin ganas de hacer nada. Habitualmente, en esa situación, me "espatarro" en el sillón y miro (que no veo) cualquier "telerollo" que echen.

Hoy, sin embargo, al dedicarme a programar, depender únicamente de mi mismo y encima, sin que se me presenten grandes problemas, me he ido a casa feliz. No es que vaya feliz porque he programado, sino que simplemente voy como más relajado, sin problemas instalados en la cabeza, y llego a casa con ganas de seguir haciendo más cosas.

¿A alguien le pasa algo parecido?

En fin, tendré que pedir que me "desciendan" y dedicarme oficialmente a programador puro y duro.

Apr 08

Más … ¿planificación de proyectos?

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.

Mar 28

Del código a la gestión

Bueno, sigo con mi rollo y con mi pena.

Al tener demasiada gente a la que "llevar" (entre comillas porque es solo de boquilla, oficialmente no llevo a nadie, extraoficialmente sí, y en la realidad a nadie salvo a cuatro gatos que me hace caso), cada vez me voy dando más cuenta de que no puedo meterme demasiado al nivel del código, porque entonces no abarco lo que debo y soy un cuello de botella para los que realmente trabajan. Tampoco puedo meterme en un nivel detallado de diseño hasta llegar al nivel de clases, por el mismo motivo. Cada vez me doy más cuenta que tengo que quedarme en un nivel alto de diseño: módulos, relaciones entre ellos, ejecutables, etc.

Pero hay una pena. A ese nivel de diseño el trabajo es aburrido y repetitivo. En un nuevo proyecto o herramienta a realizar piensas un par de días en la arquitectura, pero no hay tantas arquitecturas a elegir ni opciones. Luego es un trabajo aburrido y repetitivo de dibujar con UML o de otra forma una y otra vez lo mismo, las mismas arquitecturas, los mismos patrones de diseño de alto nivel, símplemente cambiando nombres de módulos.

Así que el trabajo acaba siendo más de gestión. Una vez que has perdido tu tiempo haciendo el mismo dibujito de la otra vez, o uno muy similar, no te queda más remedio que dedicarte a ver cómo avanza el tema, cómo se va programando, probar de vez en cuando o revisar aleatoriamente trozos de código para ver si más o menos va siguiendo la estructura general.