El problema del feedback

Últimamente estoy un poco obsesionado con el feedback y no en especial con la información que me llega, que eso es tema para otro post, si no por la información que soy capaz de usar de forma adecuada.

Parto de la premisa de que no soy una persona tipo seguramente para nada de lo que desarrollo y es muy posible que lo que para ti sea la feature del siglo, para los demás sea algo que está ahí, pero que le importa muy poco.

Recientemente me ha pasado. He creado una herramienta para exportación de datos de agroguía al PC, de forma que en google earth puedes ver los trabajos realizados. Para mi la feature mola la leche, pero a los agricultores parece importarles muy poco. Lógico, ya que no suelen usar el PC para hacer este tipo de cosas (salvo excepciones), así que era de esperar.

¿Es una __cagada__ o una pérdida de tiempo? pues posiblemente comercialmente lo sea, por lo menos en este momento. Podría haber invertido ese tiempo en una feature más solicitada? seguro que sí y además seguro que gracias a esa feautre podría haber vendido más, pero y lo importante que es estar contento con lo que haces? y el feedback que puedo obtener de esos datos? Como dice Steve Jobs, espero poder algún día unir puntos hacia atrás. También opino, aunque sea una osadía nisiquiera comparar mi afirmación con la suya, que tarde o temprano todo lo que has aprendido/hecho servirá para algo.

Me voy a dar un paseo por el campo a darme feedback y despejarme un poco, se encuentra cosas curiosas:

- Un conejo a 2 metros de mi, con lo asustadizos que son:



- Hay cosas curiosas, cosas que todos los días ves y nunca te paras a pensar. Últimamente me ha dado por los pivots de riego... en esta foto se ve perfectamente como las bocas de más lejos echan más agua sobre el cultivo, parece lógico si piensas el área que cubre cada una sabiendo que al proporción de agua debe ser constante (o no, imaginemos que tenemos mapas ed rendimiento...)

Modales en autovía

Este post se sale complemtamente de la temática ya de por si difusa de este mi blog. Paso un buen rato cada día al volante, todo por autovía, y me canso de ver subnormalidades sin parar. Estas normas son "normas no escritas" (aunque quizás deberían estarlo), pero son de sentido común, y cualquier persona al volante en una autovía debería conocerlas, allá van:

- Si vas a 150 es TU problema, no me pidas paso ni me pites si estoy en el carril izquierdo a velocidad legal. Habitualmente suelen ser conductores de, o coches de alta gama, o coches con cierta "estamina". Esto nos ha pasado muchas veces a todos, llega el típico fulano a toda leche y nos pide paso cuando estamos a medio adelantamiento de un camión.

- No voy a correr más porque te pegues más. Es causa de lo anterior, hay gente que se pega en tu culo y se cree que son capaces de reaccionar en 3 metros.

- El intermitenten izquierdo sirve para: desplazarse del carril derecho al izquierdo, pero NUNCA para permanecer en el izquierdo. Si permaneces en el izquierdo con el intermitente izquierdo puesto indicas al de delante que quieres adelantarle.

- POR FAVOR, SEAMOS DINÁMICOS EN LOS ADELANTAMIENTOS: Por mucho que salgas al carril izquierdo 500 metros antes de llegar al camión no pienso quedarme a 90 en el carril derecho. Hay mucha gente que se pone a adelantarte justo cuando llegas detrás del camión, con lo cual te toca pasar a de 120 a 90. Es facilísimo pisar un poco más para adelantar antes o incluso levantar un poco para dejar pasar. Otro caso es cuando hay una cola de camiones, suficientemente distanciados y una persona se queda en el carril izquierdo... por qué no te metes al carril derecho, los demás procurarán no dejarte metid ahí.

- Que tu coche sea potente me da igual, si me salgo al carril izquierdo para dejar que te incorpores en la autovía, déjate adelantar y luego ya acelerarás. No hagas la puñeta de acelerar y adelantar por el carril derecho.

- Trata de no joder con la velocidad: hay gente que pasa de 90 a 120, luego 140, frena... hay otros que aceleran cuando llegas a su altura (qué te hace pensar que si antes estaba a 3km y ahora a 50metros vas más rápido que yo?), aceleran cuando te adelantan y luego se ponen a ir más despacio. Vale, para los coches que no tengan control de velocidad no es tan fácil o por circunstancias debes ir más despacio, pero me he encontrado con casos de ir adelantándonos 100km sin yo tocar en control de velocidad (y creedme que es preciso, aunque tenga un poco de sesgo)

- No salgas a 60km/h a la autovía. NO ME JODAS, pisa al coche por una vez en tu vida y sal a una velocidad decente, por tu seguridad. He visto verdaderos animales saliendo a la autovía a 50km con coches de 140cv. Con un coche de 100cv en un carril de aceleración normal puedes llegar a salir a 130-140km/h, así que pisale que el coche no se rompe.

- No me voy a picar. No voy a echar carreritas por la autovía, así que cuando me adelantes no me mires amenazante, no me des ráfagas ni me pites. Si eres tan tonto de dar 3/4 de rotonda por el carril derecho y te he adelantado, espabila y aprende a coger las rotondas. Es muy común que, sobretodo los makis, se piquen poque les pases en las rotondas.


y un extra para los salmantinos:

- Las rotondas tienen DOS carriles
- PARA QUEDARME EN LA ROTONDA NO DOY EL INTERMITENTE IZQUIERDO. sí, señores, la gente de salamanca para indicar que no va a salir de la rotonda da el intermintente izquierdo. Yo que el 90% de las veces voy por el interior, no sé si es que se quedan en la rotonda o es que se cambian al carril del centro. ODIO profundamente estas normas "de facto" que la gente sigue como ovejas... va un subnormal, lo hace un día y todos a hacerlo. Sé que hay gente que hace la tijera y se va del carril central hacia fuera de la rotonda, pero qué le vamos a hacer.

Aprendiendo a negociar

Cuando te enfrentas a algo nuevo, además de la sensación de que no tienes ni puta idea, intentas aplicar el sentido común: "a ver si yo vendo esto a tanto y ellos lo quieren vender a tanto podría intentar vender a esto para ganar X". Pero una vez has terminado de pensar eso dices: "y si lo vendo demasiado caro y si es demasiado barato y me pillo los dedos...". Realmente no tengo nada con qué comparar, no tengo esa percepción interna de por donde van los tiros. Me pueden preguntar cuanto tardaría en programar un sistema que hiciese tal y cual, y más o menos puedo dar una estimación en base a mi experiencia y conicimiento, incluso si no supiese nada, podría irme a sitios donde puedo encontrar información.

Sin embargo aquí estoy perdido, nisiquiera sé donde buscar información ni conozco a nadie que sepa del tema, es más, nisiquiera sé si hay una profesión que se dedique a negociar (tal vez un comercial? uff!).

El caso es que tengo ahora mismo dos peticiones para distribuir agroguía internacionalmente (jaja, qué bien queda) y realmente __estoy muy perdido__. De todas formas, como agroguía es mi "plan B", si pierdo tampoco he perdido mucho y si gano a lo mejor me puedo compar un coche para hombres como buen hombre de negocios, como si fuera un comercial y eso siendo un tecnicucho :). Me hace gracia, me imagino la cara que se les quedaría a la otra parte si supieran que el que está al otro lado es un chaval de 26 años que no tiene ni zorra. A lo mejor lo saben e intentan aprovecharse... Hay tantas pregunas que me parece hasta divertido.
De momento aquí lo estamos haciendo bien, creo que somos los únicos aquí que vendemos por internet, así que eso es ya un paso... estoy preparando además la nueva web de agroguia, no es gran cosa, pero mejora bastante la actual.

¿Alguna sugerencia/experiencia?

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"