a vueltas con el software de mi coche

Sigo dándole vueltas a la reprogramación que hicieron en mi megane el otro día. La reprogramación solucionaba un problema en el que a causa del sobrecalentamiento de “algo” del aire frio (me imagino que serán los disipadores de calor, viva el ciclo ese del frio calor) ardía “alguna parte” y esta a su vez la correa de la distribución, con la consecuente avería. A priori no debía de tocar para nada la inyección de gasoil, símplemente tendrían que parar el compresor del aire acondicionado para evitar sobrecalentamiento, sin embargo el mapeo de input del acelerador a la inyección de carburante ha cambiado, ahora hay un lag, sobretodo en primera, que me molesta muchísimo.

He hablado con el taller oficial para ver si podían reprogramarme el sistema con el anterior mapeo y no es posible, por tanto he enviado un par de correos a renault… no voy a conseguir nada, pero igual que a mi me gusta recibir feedback (que no bugs, eso no le gusta a nadie) del software que hago, estaría bien que los que programan las centralitas sepan que me tienen hasta el gorro :).

horas de la jornada laboral

Cuántas horas son necesarias, o mejor dicho, óptimas en la jordana laboral de un desarrollador? Desde que he escuchado en la radio algo sobre jornadas de 65 horas semanales (no pongo links porque lo he escuchado y tampoco lo he dado mucha importancia) me hago esa pregunta.

Personalmente tengo tendencia a trabajar de más, me da la impresión que ya es vicio, aunque sí que me doy cuenta que al final del día, delante del monitor, me cuesta mucho escribir código o pensar cosas relacionadas. Cuanto realmente soy productivo de verdad? mi opinión es que puedo llegar a ser productivo unas 4 horas al día como máximo, esto es, centrado en lo que estoy haciendo, con toda la atención en ello y con cierto “gusto” por ello, lo que ahora llaman, “estar en flujo”

Me pregunto, sería mejor tener una jornada laboral de menos horas? cuántos bugs o fallos se cometen por culpa de no estar “en flujo”? cuántos se cometen cuando lo estás? mi opinión es que 8 horas son una burrada, aunque no todo es estar programando, la jornada laboral se compone de:
- trabajo productivo directo, que es hacer trabajo *real*.
- indirecto, que es estar aprendiendo cosas nuevas, leyendo documentación, libros, etc
- trabajo que no “sirve para nada”, esto es, el de gestión y digo que no sirve de nada porque no añade nada al trabajo final, es algo que está ahí y es necesario, pero si no necesitasemos ese tiempo no pasaría nada. Aquí incluyes la formación a otras personas, etc.
- descanso: cada X tiempo es necesario parar

Es difícil calcular, pero por ejemplo, cuando hay jordana continua de 7 horas, mi vida mejora enteros y creo que mi producción aumenta a pesar de trabajar una hora menos.

¿Es proporcional la producción al número de horas?

Aunque hay muchas cosas que aumentan la productividad, pero eso es tema de otro post.

El trabajo en equipo

Estaba yo viendo el siguiente video:

Y pensaba cuantas personas hay ahí funcionando, ya no solo haciendo la música, que con eso bastaría, pero es que además está sonido, iluminación, cámaras, realizador… etc, etc, todo perfectamente coordinado y sincronizado.

No todo sale bien, el de sonido al principio le pone el retorno de audio muy alto y la jode los oidos a la cantante, de ahí que la mujer se apresure a bajarlo en la pecata amarilla que lleva dentro del bolso, el realizador la caga en el plano en el que mike oldfield se está peleando con la bufanda, etc, pero en general todo va perfecto, todo sigue, la cantante continúa cantando, el realizador da un plano para que no sea vea como toca la petaca, mike oldfield la caga con la guitarra pero sale del aprieto de puta madre (ver el comentario de un tal “richaxes” en youtube).

No sé la cantidad de personas que estarán trabajando ahí, pero me asombra ver como se pueden coordinar. Desarrollando software formas un equipo de 3 personas y ya la has liado, ya necesitas por lo menos un coordinador para que la cosa marche. Me da un poco de vergüenza, la verdad, sobretodo teniendo en cuenta que, por ejemplo, la cámara de atrás, esa que va volando por encima mike oldfield requiere de 3 personas para controlarla, pero ahí están, dando buenos planos, coordinados con otros tantos cámaras, el realizador, la canción…

Cuanto nos queda por aprender en el desarrollo de software, quizás cuando llevemos años y años haciendo lo mismo podamos ser tan buenos :).

RTS procedural

Estaba viendo los resultados de la compo de Tigsource sobre juegos con contenido procedural y bajandome los más llamativos me encuentro con Dyson. Se trata de un juego de estrategia, donde hay una serie de asteroides que tenemos que colonizar con una especie de moscas. En cada asteroide plantamos una serie de árboles (L-tree claro está) que nos permiten generar más moscas. Para colonizar un asterisco asteroide hay que enviar una cantidad suficiente de moscas… el juego no deja de ser lo mismo que todos los RTS actuales, una serie de recursos para generar unidades y conquistar más recursos.

El juego es simple, pero muy adictivo, además el apartado gráfico cumple perfectamente, da gusto ver como se mueven las moscas como un fluido cuando tienes más de 100. Merece la pena probarlo.

A ver si sacan los resultados y pruebo los mejores juegos porque en la compo hay demasiados juegos para probarlos todos.

Metodologías: ¿sí o no?

Llevo un tiempo leyendo algunos libros y artículos sobre metodologías además de estar dentro de un proceso de adaptación a CMM2. La gestión de proyectos es compleja, por lo menos desde mi visión actual con más bien escasa experiencia, y aún no tengo muy claras las cosas.

Resulta que el objetivo del desarrollo es tener algo tangible, algo que se pueda usar, que sea útil y en el que cuanta menos burocracia haya mejor. Esto es aplicable no solo al desarrollo de software, si no a cualquier proyecto, pero yo no sé que pasa que en todos los proyectos/negocios que veo al final se consume más tiempo en burocracia que en desarrollo.

Si tienes una empresa de 100 empleados parece lógico que la burocracia aumente, sobretodo porque con 100 empleados tienes mucha probabilidad de que tengas a mucha gente no muy buena en su trabajo, poco motivada, etc. Es normal que se tengan que marcar unas reglas estrictas de funcionamiento.

Me planteo si de verdad usar metodologías muy severas aporta algo a proyectos dinámicos, los cuales se adaptan de forma rápida a las necesidades o si estoy confundido y es necesario un control muy cerrado para llevar un proyecto a cabo con una calidad profesional.

Al final creo que el camino se hace al andar, que las metodologías describen los procesos que se han ido mejorando a lo largo del tiempo y que de verdad han demostrado que funcionan después de probar variantes, ver el resultado y sobretodo cargarla. Al final si el equipo es bueno y estila buenas prácticas la metodología aparece sola.

Me recuerda a una frase que leía en una bodega de un familiar: “una buen vino puede arreglar una mala comida y uno malo estropear una buena”