2018

Es curioso como haciéndo este ejercicio anual de recopilación de intenciones recuerdo a dejo de recordar los propósitos. Este año he logrado casi sin querer algunas de las cosas que me planteaba.

  • He viajado “bastante” con la familia, y nos lo hemos pasado bien.
  • A nivel laboral he empezado en Sherpa, que es lo que buscaba, una empresa 100% de producto. Solo llevo tres meses pero de momento bien.
  • Sigo dibujando (mal), aunque por alguna razón hay gente a la que le gusta.
  • A nivel de salud todo ok, aunque me sigue sobrando lastre.
  • El mundo es un poquito más feminista y yo también. Me resulta bastante sorprendente la resistencia de algunas personas humanas al respecto (seguramente a otras le sorprenderá la mía).
  • He subido algunas montañas, ninguna muy alta, un poco “fail”.

Para el 2019:

  • Seguir progresando a nivel laboral, sin volvernos locos, que es la línea de estos años.
  • Igual diversificar mi actividad “artística” (si se puede calificar así) tocando la guitarra un poco. Dibujar libros además de charlas (lo cual es mucho más laborioso, espero que a la par que productivo).
  • Subir más montañas. Se me ha pasado por la cabeza otro maratón pero creo que será demasiado. Bajar un poco de culo en el proceso.

Txispum

Anuncios

Codice software

Hice en un proceso de selección con Codice Software antes de empezar en Sherpa. Al final no pudo ser, pero he conocido un poco mejor esta empresa de Valladolid.

Entre otras cosas, hacen Plastic SCM (@plasticscm), un control de versiones que empezaron en 2005 (el mismo año que Git y Mercurial), y ahí siguen, vendiendo licencias. Puede trabajar distribuido y centralizado y va fino con ficheros muy grandes, por lo que es muy popular entre desarrolladores de video juegos y cosas así. Con tantas soluciones a este problema, algo tiene que haber ahí detrás para que sigan funcionando.

Hasta aquí ya me lo sabía antes (más o menos), pero hay algunos detalles que descubres leyendo su blog… empezaron con bases de datos tradicionales para no reinventar la rueda, pero al final vieron que igual les hacía falta… y crearon Jet, su propia implementación optimizada que parece que les va como un tiro.

Tienen también una serie de entradas dedicadas a como hacen su ciclo de desarrollo y de release, muy interesante también: son varias entradas, enlazo algunas .

Otra cosa que me alucinó es que tienen más de 50 horas de pruebas automáticas que corren en 2-3 horas lanzandolas en paralelo. ¡Son un montón de pruebas! Y además hacen code review de todo (soy muy fan de esta práctica).

Nota al margen: tendré que leer Code Complete, lo recomiendan mucho 🙂

Como con Nunit no les bastaba, pues se han creado Punit para que todo sea más paralelo (y acabe antes claro).

Otro producto que tienen es el “merge semántico“, que entiende el código y detecta, por ejemplo, cuando mueves un método de clase .

Y hoy en día con .NET Core el desarrollo multiplataforma es otra cosa, pero esta gente lleva dándole a Mono desde hace muchos años… como curiosidad Mono&Solaris.

En fin, un empresón de talla mundial que tenemos ahí mismo y no nos damos cuenta. Aunque solo conozco a @rdealbade y a @psluaces, hay muchas personas ahí detrás.

Un último detalle: El lema de plastic es “I’m Plastic, I solve problems”, toda una declaración de principios, que me recuerda a esto (no sé si está relacionado, la verdad).

Sherpa

Llevo ya más un mes en Sherpa, trabajando como Backen Team Leader, que quiere decir que soy el señor mayor con el que habla el resto del equipo cuando no tiene algo claro. Es una empresa plenamente de producto, que era lo que buscaba cuando salí de Plain Concepts.

En Sherpa hacemos un  asistente personal que aspira a superar a lo mejor del sector, aprendiendo de ti y siendo capaz de anticiparse a tus necesidades, Algoritmos predictivos, perfilado de usuarios e inteligencia lingüistica son cosas que hacemos, y entre otras cosas, Porsche se ha fijado en nuestra tecnología.

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.

 

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.