Vida nueva

Después de tres años estupendos en Plain Concepts, he decidido empezar una aventura nueva. En estos tres años he aprendido un montón de cosas a todos los niveles. He aprendido mucho sobre herramientas del entorno Microsoft, he aprendido a trabajar en un equipo con un un nivel humano y profesional altísimo, y he aprendido que manejar un equipo como creo que hay que manejarlo funciona bien en el entorno adecuado (hasta ahora esto era más o menos un hipótesis)(y es cosa de Rodrigo).

¿Y por qué decido entonces salir? Porque también he aprendido que trabajando para terceros se encuentran demasiados obstaculos para llevar los proyectos a buen puerto. Mejor dicho, llevarlos de la mejor manera posible. Porque he estado en varios considerados un éxito que bajo mi punto de vista han sido un fracaso, o al menos podían haber funcionado mejor.

Dicho esto, busco:

  • Una empresa de producto propio, donde estar más cerca de las decisiones tener más tracción a la hora de impulsarlas.
  • Con un equipo de alto nivel con el que poder aprender.
  • Que me permita trabajar en el area de Bilbao (remoto o presencial).

Qué ofrezco:

  • Muchos años experiencia (soy un señor mayor).
  • Capacidad para aprender cosas (más o menos) rápidamente.
  • Criterio a la hora de tomar decisiones y resolver problemas.
  • Alta capacidad para trabajar en equipo, incluso liderándolo.
  • Desarrollo ágil en el más amplio sentido de la palabra.

Así que si te hace falta personal, y te cuadra, ya sabes.

 

Anuncios

Pull request

Estos días ha surgido en un cliente un viejo debate sobre como gestionar los cambios en una base de código. La cuestión es que les ha parecido buena idea cerrar las actualizaciones sobre la rama de desarrollo, y ahora solo podemos hacerlas vía pull request. Vamos, que no podemos hacer “push” directamente sobre la rama de dev. Como me gusta cero la medida, voy a escribir en esta entrada las razones a favor y en contra de dica medida. A favor:

– Permite controlar los cambios. Solicitar un pull request obliga a “pedir permiso”, alguien tiene que aprobar dicha petición, revisando el código.

Aquí acaba la lista de ventajas (ya he comentado que no estaba a favor 🙂 En contra:

  • Realmente no controlas nada, solo estableces un mecanismo que impide que actualicemos la rama en cuestión. Puedes aprobar el pull request sin leer el código, o leyendolo en parte…
  • Puedes que compartas o no conocimiento. Si haces pull request sin hacer revisión de código la estamos liando.
  • Ralentizas el desarrollo. Hay que esperar a que alguien apruebe esa petición, con lo que dichas peticiones se pueden acumular y ralentizar el desarrollo en general.
  • Se complica la gestión de ramas. Si saco una rama la quiero proteger con una build que me garantice que todo va bien en dicha rama. También quiero probar en un entorno integrado dichos cambios, con lo que tendría que desplegar ese código, pero realmente no está “aprobado” con lo que estoy desplegando “en falso”. En fin, todo se complica.
  • Se dilatan las integraciones en el tiempo con lo que se maximiza la posibilidad de que aparezcan problemas, precisamente de lo que huyes si estás haciendo integración continua.

Algunos argumentos que me han dado para justificar esta medida:

  • Al principio vas más lento, pero a la larga más rápido”. Aunque entiendo y comparto la idea última de esta frase, la pull request no garantiza nada. Una cultura del equipo apropiada me parece mucho más acertada a la hora de llevar este control, que de hecho es lo que hacemos contiuamente con revisiones de código.
  • Así aseguramos el traspaso de conocimiento porque ahora dependemos demasiado del proveedor“. Depender del proveedor cuando externalizas un desarrollo no es un problema asociado, es algo que va a pasar si o si, no hay otra opción. Aunque veo muy bien el intentar traspasar ese conocimiento, una vez más no creo que la pull request asegure nada, sino que habría que trabajar ese traspaso de conocimiento.
  • No se si esto es agilismo pero nos funciona“. Ok, no es agilismo, eso está claro. Si funciona o no igual hay que demostrarlo de alguna manera. Me apunto que igual tengo que demostrar de alguna manera que funciona no usarlas.
  • Podemos tener una pull request abierta durante dos, tres semanas, pero al final está bien hecho“. Sin comentarios la verdad, si tienes peticiones abiertas tres semanas no hay más que hablar, por muy bien hecho que esté al final si tienes más gente en ese desarrollo trabajando se obstaculiza seguro.

Mi conclusión es clara, no estoy a favor de este tipo de medidas de control, aunque el fondo puede no ser tan negativo y seguro que hay maneras de hacerlo funcionar. De todas maneras, cada uno hace con su base de código lo que quiere. Eso si, que no cuenten conmigo 🙂

PD: Casualmente he encontrado estos días este enlace en Twitter (via @gabrielmora) hablando de algo parecido, trabajar sin ramas (si haces pull request es obligatorio usarlas

 

2017

El año 2017 ha sido un buen año a varios niveles:

  • Creo que he conseguido un buen equilibrio en lo personal/profesional. Hay cosas que intento no hacer, como sobretrabajar sistemáticamente o asistir a eventos en fin se semana (aunque a veces me lo salto). Por mucho que me guste lo que hago supone demasiado a largo plazo.
  • He sido ponente en la CAS, y he repetido esa charla un par de veces. Me ha encantado la experiencia, y el resultado ha sido bien valorado (que no estaba muy seguro), con lo que estoy muy satisfecho al respecto. No se si repetir es un objetivo muy realista, porque aunque ha salido bien deber.
  • A nivel de salud no he tenido sobresaltos. Algún kilo de más que habrá que corregir, que mi espalda no está “para mochilas extra”.
  • A nivel laboral, ya no soy un novato en .Net&Family. Sin ser un gran experto, no tengo que googlear/preguntar todo. En el lado no tan positivo, la consultoria es una ruleta, y no controlas muchos aspectos de lo que estás haciendo, porque están en el lado del cliente.

Para 2018 me pido:

  • A nivel laboral, encontrar un proyecto chulo, que sea interesante tanto técnica como funcionalmente, y verlo funcionar (y producir). Demasiadas de mis líneas de código y otras cosas se han ido por el retrete, me gustaría ver lo que hago funcionando en el mundo real (y teniendo un éxito descomunal si es posible).
  • Dibujar de dibujar, no de hacer monigotes rápidamente. No lo sabía, pero me gusta. No es que se me de especialmente bien, pero soy bastante cabezón.
  • Eliminar sobrepeso haciendo deporte, y disfrutar de ello. Subir más montañas estaría bien (incluyendo alguna bien alta).
  • Ser más feminista. Mi generación creció pensando que el machismo era cosa del pasado, y nos colamos. Así que algo habrá que hacer para remediarlo.
  • Disfrutar con mi familia viajando.  Me gusta viajsar y disfruto planificando estos viajes, para este año voy a ver si me organizo con tiempo que el verano pasado nos comío la vida.

Urte berri on!

Cas 2017

En esta edición de la CAS 2017 he tenido la oportunidad de hacer una charla titulada “En mi equipo funciona pero no sé por qué”. Os dejo aquí el extracto:

En la comunidad Crafter apostamos por las cosas bien hechas… pero nos basamos en “sensaciones” y experiencias puntuales para elegir prácticas y técnicas.

Existen aún pocos estudios y menos evidencias con las que poder elegir las prácticas y técnicas con una base científica, y lo que hay se conoce poco.

¿Es posible tener evidencias científicas en la que apoyarnos más allá del “en mi equipo esto funciona” a pesar de las dificultades que plantea?

Después la he hecho también con Bilbao Crafters y Gasteiz Developers, vamos que le he sacado chispas y me ha faltado solo Donosti para conquistar Euskadi. La verdad es que el feedback ha superado todas mis expectativas y estoy encantado con los resultados (y además me lo he pasado pipa preparándola).

Dejo por aquí un montón de enlaces relacionados, los #dibujitos que yo mismo he hecho, la presentación y el video que el estupendo equipo de Autentia ha subido:

Cambiando de Java a C# (y todo lo demás)

El 7 de setiembre de 2015 comencé a trabajar en Plain Concepts, que se caracteriza por hacer las cosas bien (o al menos intentarlo) y por ser partner de Microsoft, con lo que empecé a pegarme prácticamente desde cero con un montón de cosas que no conocía (básicamente todo la tecnología orientada al desarrollo de Microsoft, Windows me sonaba un poco). Desde el Visual Studio al IIS, pasando por .Net en general y webAPI en particular, y terminando en Azure, era todo nuevo.

Es una sensación extraña cuando lleves 18 años dedicado profesionalmente al desarrollo ver que no sabes hacer la o con un canuto, y que cualquier cosa es nueva. Por mucho que quieras estudiar a nada que tengas que hacer algo que vaya más allá del tutorial básico de algo se te va a escapar, así que es este tiempo me ha tocado resolver un montón de ¿lagunas? de manera práctica.

La parte positiva es que, sin saber hacer la o con un canuto, he podido sacar adelante proyectos durante este tiempo. Voy a decir que me ha costado al menos un año sentirse cómodo de verdad con el entorno de trabajo. No es que ahora sea ni mucho menos un experto, pero al menos no tengo que preguntar y/o googlear todo lo que escucho.

Para todo esto ha sido fundamental el equipo con el que estado trabajando, que por un lado tiene una experiencia brutal con las tecnologías que usamos y por otro lado una capacidad técnica y de superación importante. Sin toda esta gente del equipo de Plain Bilbao hubiera sido mucho más complicado progresar tanto y tan rápido.

No descubro ningún secreto si digo que en este mundo es fundamental saber aprender cosas nuevas, porque la tecnología es algo en constante evolución y continuamente hay que mantenerse al día de esa evolución, aunque en mi opinión sin volverse loco porque a veces estamos es una carrera que es complicada de correr, y en la que es fundamental dosificar esfuerzos porque no puedes abarcarlo todo, hay que seleccionar lo que quieres y/o necesitas aprender y encontrar el momento para hacerlo (y también saber cuando no hacerlo porque no sirve para nada o no es el momento).

“En mi equipo funciona…

… pero no sé por qué” ha sido el título de la charla que me han dejado hacer en la CAS 2017. Es un tema que me interesa desde hace bastante tiempo, empezando por una pequeña reflexión en el ámbito de un grupo de estudio sobre las pruebas científicas que respalda usar TDD (basado en hilo de Agile Spain que lo debatía), pasando por entradas de este mismo blog, una charla-debate en la Pamplona Software Crafters de 2015 y terminando en esta charla. Si tengo que facturar por horas las que he metido prepárandola a lo largo del tiempo claramente no me sale rentable 🙂

La verdad es que el feedback ha sido para mi excepcional, sobre todo si tengo en cuenta que más una y más de dos veces he pensado que probablemente todo esto solo me interesaba a mi, y que el resto del mundo lo iba a considerar irrelevante y poco interesante.

Además de esto, algunos comentarios por otros canales como Twitter y personalmente me llenan de “orgullo y de satisfacción”, parece que ha gustado a gente que considero que tiene bastante criterio. Así que encantado.

Os dejo el enlace a la presentación, unos cuantos enlaces relacionados y en el futuro el video porque ha sido grabada.

#EstimacionesLasJustas

 

TL;DR

Estimar muchas veces no nos aporta nada (¿realmente es necesario saber cuanto tardaremos?) y cuando aporta no podemos confiar 100% en estas estimaciones porque son eso, estimaciones que dependen de que contrastemos varias suposiciones con la realidad. Por ello no conviene invertir demasiado en ellas ni creérselas demasiado.

A partir de una conversación en Twitter, comienza una discusión sobre las estimaciones… ¿Deben ser en horas o en complejidad?

Personalmente lo he hecho de las dos maneras, y las horas, bueno son… horas, que podemos medir y gestionar qué tal vamos, con lo que enseguida se traducen a fuego a compromisos que cumplir. En general somos muy malos estimando, con lo que es mala idea hacerlo transmitiendo esa sensación de seguridad: “esto tardo en hacerlo 23 horas”, parece que está muy controlado (y no es así). Además transmiten también otra idea y es “cobro por hora” al peso, y (donde yo trabajo) preferimos medir el valor aportado, porque si me miden en horas simplemente alargaré las horas que necesito, y eso es diferente de ideal.

Me gusta más lo de los puntos porque se supone que somos mejores midiendo relativamente (aunque seguimos siendo bastante malos). Y esa complejidad relativa acumulado me permite usar cosas como la velocidad (hacemos tantos puntos por iteración) que puedo utilizar para ajustar plazos más fácilmente que con horas. Es decir, si por la razón que sea no hacemos los puntos que pensábamos por iteracion, puedo recalcular plazos de manera sencilla: me quedan x puntos por hacer, y hacemos y por iteración, luego acabaremos (si nada se mueve) más o menos en x/y iteraciones.

El planteamiento de medir complejidad en puntos suena muy bien en el plano teórico, pero en la práctica tenemos (al menos en mi experiencia) una tendencia muy acusada a olvidarnos de que son relativos y asociar puntos a jornadas, con lo que acabamos… estimado horas. Así que hay tenemos un margen de mejora.

Otro punto del debate era ¿para que estimamos? En un mundo ideal no nos hace falta para mucho. La persona que pone el dinero confía en el equipo y le da igual 5 que 50, quiere el producto ideal al precio que sea en el tiempo que sea (y probablemente en algún momento ha visto que aunque fuera contra pronostico la cosa funciona). En el mundo real queremos un presupuesto (aunque sea aproximado) y un plazo (aunque sea aproximado). Muchas veces esto es un sinsentido porque acabamos teniendo plazos y presupuestos muy inexactos, simplemente porque es lo que se demanda. Otras veces hay intereses que conjugar y acciones que coordinar, y hacen falta estimaciones  para poder tomar decisiones. Dicho esto, creo que hay que procurar no cometer dos errores:

  • No te las creas demasiado. Son estimaciones “adivinadas”, no sabemos lo que vamos a encontrar hasta que empecemos a hacerlo (sino es porque ya está hecho, reenfoca el proyecto).
  • No emplees demasiado tiempo en hacerlas. Esto es fácil de decir y difícil de hacer si te piden un presupuesto para un proyecto mayor que mediano, así que si eres quien pone el dinero y te aseguran plazos y alcance casi seguro que saldrá mal.

Ahora bien, no nos olvidemos de todo el trabajo que se hace en torno a la estimación para afinar las historias, desgranarlas e incluso enfocarlas técnicamente. Ese trabajo es bajo mi punto de vista esencial para que el equipo entienda lo que estamos haciendo de manera colectiva, y es un beneficio”colateral” que obtenemos estimando, aunque podríamos obtenerlo sin estimar estrictamente hablando.

Por todo esto, #estimacionesLasJustas, cuando sean realmente necesarias, sin inversión desproporcionada y sin creérnoslas del todo.

Calidad

Dentro del mundo del desarrollo y de la gestión de proyectos, se habla mucho del “triángulo de hierro”, de las tres dimensiones con las que podemos manejar en un proyecto: tiempo, alcance y coste. A menudo se habla también de otra dimensión oculta que es la calidad.

Desde algunos puntos de vista, la calidad es algo a lo que no se puede renunciar, porque a largo plazo se vuelve contra tuya. Si descuidas este aspecto, a largo plazo tu base de código se volverá difícil de interpretar y de extender, los errores se multiplicarán y serán más difíciles de solucionar… Lo sé porque he estado ahí muchas veces.

En Plain Concepts apostamos mucho por asegurar la calidad del software que escribimos, y estas son algunas cosas que hacemos para intentar mejorarla:

  • Trabajar en equipo (I). Eso significa que las decisiones importantes, las estructura de las soluciones, las arquitecturas, se deciden en común, dentro del equipo. Esto lleva a un debate que pensamos redunda en mejores soluciones que las que puedes pensar tú solo, por muy listo que sea.
  • Trabajar en equipo (II). Trabajar en equipo también significa que cuando tienes un problema, puedes recurrir al equipo para desatascarlo de la mejor manera posible (una vez más mejor solución que pensándola tú solo).
  • Pruebas automáticas. Una de las variables hablando de calidad son los errores; evidentemente cuantos menos mejor, y desde un punto de vista de sostenibilidad, esto no se puede hacer con pruebas manuales, porque llegaríamos a un punto de pasar más tiempo probando que desarrollando. Por eso apostamos por las pruebas automáticas, sin obsesionarnos con el 100% de cobertura.
  • Demo con cliente. Trabajamos en sprints, así que entregamos software funcionando al final de cada ciclo. Esto significa que el cliente puede y debe probarlo y reportar errores. Esto no es siempre así (y habría que mejorarlo) pero de todas maneras el sprint siempre culmina con una demo con cliente en la que enseñamos y probamos ese software funcionando.
  • Demos internas. Para asegurar (entre otras cosas) que esa demo con cliente va bien hacemos una demo interna anterior a la demo con el cliente, de manera que tenemos un pequeño margen de mejora por si algo no sale todo lo bien que debiera. En esta demo también se tratan y discuten otros aspectos del proyecto.
  • Desarrollar en pareja. El “Pair programming” es un mundo en sí mismo, y quizá no es para todo el mundo ni para todas las ocasiones, pero nos ayuda a tomar mejores decisiones.
  • Revisión de historias. Cada historia finalizada se valida con otro miembro del equipo y contra una “Definición de hecho” que repasamos para ver si todo está en orden. Esta lista incluye cosas como validar en un entorno de integración, revisión de código, pruebas automáticas…

En algunas ocasiones, nos hemos encontrado con proyectos que se desvían del estandar de calidad que consideramos apropiado, así que estamos barajando alguna medida más.

  • Revisiones de código. Las revisiones de código que hacemos centradas en una historia a veces no te dan una visión general del proyecto, o igual no es el momento de revisar cosas como la congruencia de las decisiones tomadas a lo largo del proyecto, con lo que necesitamos otros momentos en los que revisar estos aspectos. Le estamos dando forma como revisiones de proyecto, que se convocan periódicamente.
  • Evitar los proyectos “monopersona”. Es complicado en algunas situaciones con proyectos pequeños, pero en la medida de lo posible sería deseable evitar este tipo de proyectos, para poder contar con al menos otro punto de vista a la hora de tomar decisiones y evitar que sean demasiado individuales.

 

Gremios y metaforas

Uno de los problemas que tenemos dentro de nuestro gremio es que tenemos muchos problemas para describir que es lo que hacemos. Los que nos dedicamos a hacer software lidiamos con algo tan hetéreo, tan diferente de como se comportan el resto de elementos físicos con los que interactuamos en el día a día que se nos hace muy difícil describir apropiadamente que es lo que hacemos en general, y cuales son los condicionantes que nos encontramos para resolver cada problema concreto.

Para intentar superar esto, hemos utilizado metáforas por encima de nuestras posibilidades. Somos como artesanos, como arquitectos, como jardineros, como médicos, como calibradores de pollos… casi casi de todo. Y la última metáfora que he oido viene de Joel Spolsky. Un grande entre los grandes (construir Trello está bien, pero hacer Excel es la pera). Habla en un pequeño manual sobre desarrollo que esto es como… ¡¡conducir un taxi!! pero a veces cuando giras el volante este no responde porque tienes una persona con camiseta a rallas montado, y otras veces… no es que quiera llevarle la contraria a Joel, nada más lejos de mi intención, pero creo que ya basta de metáforas.

Como las abstracciones, todas las metáforas fugan. Reflejan un aspecto y no otro, como los modelos que todos son incorrectos pero algunos son útiles… y el problema es que en el fondo, ni nosotros mismos sabemos como funciona esto, y por eso acudimos a metáforas más o menos afortunadas para intentar explicarlo. Verás, esto es como si tal pero cual y además le añadimos que no se puede tocar y no se derrumba, pero a la vez es muy endeble… todo esto para explicar porque demonios no somos capaces como industria de hacer software robusto, de calidad que no se rompa cada dos por tres por algún lado de manera totalmente inesperada.

2016

De nuevo llega el final del año, de nuevo toca evaluarlo en unas pocas líneas. el año pasado me propuse:

  • Consolidar el cambio (profesional). Ha sido un año ¿complicado? No sé si es exactamente el adjetivo, pero no ha sido fácil. El otro día hablabamos de la zona de confort, yo llevo fuera 16 meses, con contadas excepciones. Igual ahora me empiezo a enterar bien de que va esto, pero toca seguir trabajándolo.
  • Seguir corriendo. He hecho una maraton en 4:18, más despacio de lo que esperaba pero digna. No es para mí, al menos en este momento supone demasiada dedicación, sobre todo en horas de entrenamientos. Me quedo con la media que es una alternativa mucho más sostenible en el tiempo.
  • Dibujar más. Cumplido a medias, he hecho algo y además alguno en directo, como en la CAS 2016. Todavía me sorprendo cuando la gente lo ve y me dice que se dibujar, cuando claramente esto es otra cosa distinta (y no se dibujar). A trabajar más en el futuro, a ver si aprendo.
  • Seguir haciendo compatible mi vida personal con la profesional. Creo que lo he cumplido, en gran parte porque mi empresa me da mucha manga ancha a la hora de organizar horarios, trabajamos más por objetivos.

Mención aparte para la organización de la CAS 2016, que sin estar en los planes iniciales ha consumido bastante tiempo en este 2016.

Me encanta el efecto de esta entrada anual, todos los años me parece que me tengo que aclarar a la hora de pensar en el futuro, va a ser que es una constante que hay que aceptar y ya está (No hay cuchara). A nivel laboral Plain Concepts Bilbao es un gran sitio para trabajar: te valoran profesionalmente, te dan libertad, se persigue la calidad y la maestría en lo que hacemos, y son equipo de personas excepcionales… pero hacemos consultoría y desarrollo a medida, y a veces unos proyectos molan más que otros.

Feliz 2017