Qué funciona haciendo software y por qué

En la pasada CAS hubo una keynote en la que se hablaba de estudios relacionados con el desarrollo de sofware, y de su “relativa” validez. Estoy muy de acuerdo en que algunos de estos estudios dan un poco de risa, y de hecho ya hice ese ejercicio de analizar dichos estudios hace unos años. No estoy muy de acuerdo con el mensaje, que se reducía IMHO a “No te fíes de nada, prueba con todo a ver si a ti te funciona” utilizando los mismos argumentos y estrategias que se critican cometiendo algunos errores de bulto, pero es no es la cuestión principal.
La cuestión cuando llegamos aquí es: ¿es posible medir los beneficios de determinadas prácticas desarrollando software?  San Martin de Fowler habla de la evidencia anecdótica para referirse a prácticas que funcionan en un caso como algo útil en ausencia de datos objetivos (dado que opina que no podemos medir la productividad). Efectivamente los equipos de software son sistemas muy complejos en los que es muy difícil medir como una práctica determinada influye en nuestro rendimiento más allá de sensaciones, no tenemos la regla de medir la productividad y así poder decir al finalizar una iteración que, por ejemplo, hacer programación por parejas a aumentado/disminuido nuestra productividad en un x%. Bajo mi punto de vista esto tiene varios problemas:
  • En primer lugar no tenemos esa regla para medir productividad. Normalmente funcionamos más por sensaciones, por lo que nos parece que funciona, que con datos objetivos, por lo que nos quedamos siempre en el terreno de lo discutible (y ahí seguimos, discutiendo).
  • Digamos que podemos medir la productividad en historias/puntos/loQueSea, siempre tendremos una medida relativa que para cada equipo y que sólo funciona para ese equipo, lo que limita mucho la validez y generalización de estas medidas. Eso suponiendo que funcione algo para ese equipo, porque en muchas ocasiones esas métricas no existen.
  • Aunque encontráramos esa manera de medir la productividad, si algo está demostrado es que el esfuerzo dedicado a mantener un software es mayor que el esfuerzo dedicado a su desarrollo inicial, por lo que habría que medir también la “mantenibilidad” de dicho software, lo que bajo mi punto de vista es aún más complicado.
Dicho esto, retomo la pregunta, ¿es posible medir los beneficios de determinadas prácticas? Parece complicado, y aunque existen muchos estudios de todo tipo, no hay conclusiones claras, o al menos y no las conozco. Es difícil aislar un estudio de todos los factores externos que hemos comentado, pero eso no quiere decir que sea imposible. Quizá no hemos encontrado la manera correcta de hacerlos, o quizá realmente no nos interesa contar con esos datos como industria, y preferimos movernos en el terreno de la incertidumbre, y seguir vendiendo humo que parece que funciona bien.
Hay personas en este mundo que han construido un acelerador de partículas para acelerar átomos a velocidad absurda para durante un tiempo infinitesimal podar visualizar elementos cuánticos como el Bosson de Higgs, y resulta que la industria del software no es capaz de comprobar si dos personas en el mismo ordenador programando rinden mejor que una. Francamente me resulta desolador, pero si existen intentos de llevar esta experimentación un poco más allá: https://vimeo.com/9270320 ( vía un tweet de @javisantana).

2015

Otro año más que termina. En 2015 he tenido otro cambio laboral, el anterior proyecto en el participaba dejo de motivarme por distintas razones; la principal es que básicamente no me lo creía. Una pena, la verdad, porque era un grupo de personas estupendo, pero opté por pasar página. En setiembre empecé en Plain Concepts, nueva empresa, nuevos compañeros, nuevo rol, nuevas tecnologías… todo muy nuevo. Entre otras cosas he empezado con .NET, he arrancado un IIS, utilizo Outlook y todo lo que sea Ms. Como con todo, cosas mejores y peores, pero eso es otra entrada que no se si sucederá. De momento (a falta de evaluación oficial), parece que más o menos encajo con equipo y no he hecho el ridículo en las cuestiones en las que he estado involucrado; de todas maneras, aunque progreso adecuadamente necesito mejorar, y veo que me cuesta meter horas para hacerlo. Decía Chad Fowler que hay que ser el peor saxofonista de la banda para progresar; lo de progresar no sé pero ser el peor me ha salido estupendamente.

Me está saliendo una entrada de recapitulación anual, así que vamos con los objetivos:

  • Consolidar el cambio. Encontrar mi sitio y mi papel en Plain para que sea una alternativa sostenible en el tiempo.
  • Seguir corriendo🙂 Después de una media maratón, me queda la maratón completa. No tengo claro si tengo el tiempo y la motivación necesarios, lo iremos viendo.
  • Dibujar más. Últimamente he hecho bastante sketchnoting de ese, y me apetece desarrollarlo un poco más.
  • Seguir haciendo compatible mi vida personal con la profesional🙂 suena a perogrullo pero a veces se me va la olla.

Urte berri on!!

Primera semana

Esta semana he empezado una nueva andadura en Plain Concepts, después de salir de Init buscaba algo que fuera a la vez un sitio donde aportar y aprender mucho. He aterrizado en un entorno a la vez conocido y desconocido. Conocido por la parte ágil, Plain ha sido referente en la comunidad desde siempre y su apuesta por este tipo de enfoque es clara; desconocido porque no estoy nada familiarizado con el entorno de trabajo, desde Windows hasta la plataforma .NET. Por alguna razón que se me escapa han decidido que es un obstáculo superable y en ello estamos.

Ha sido una semana de aprender un montón de cosas, de hacer muchas que no pensaba que sucederían (instalar Windows 8, Windows 10, Visual Studio, arrancar un IIS, arrancar una apliación en ese IIS, desplegar en Azure, estrenar un ordenador muy muy feo aunque muy potente…) y de situarme en dónde puedo aportar algo. En fin, espero que sea la primera semana de muchas🙂

2014

Ya llevo un par de años evaluando el año en menos de 25 líneas🙂 Este 2014 ha estado sin duda marcado por un cambio laboral. Estoy con un grupo de personas estupendas, pero aún tenemos mucho trabajo por hacer en muchos ámbitos:

  • Construir equipo. Hace 7 meses cuando empecé aquello era una banda, no un equipo. He descubierto que se pueden hacer un montón de cosas al respecto no haciendo. Sólo con estar, como el Cid, vamos. Por lo que me dicen, de alguna manera mi campo de fuerza ha contrarestado el de otras personas y el equipo se ha sentido más a gusto para tomar sus decisiones.
  • A nivel económico, necesitamos un poco más de margen para estar más cómodos. Es evidente, pero el bienestar económico te permite hacer un montón de cosas que de otra manera no puedes (ver punto siguiente). Y con esto me refiero a pagar a proveedores, gastos a los trabajadores, ajustar las nóminas a la valía e incluso el dinero que nos gastamos en un ordenador, un curso o un libro.
  • Respirar. Desde que llegué, no dejo de repetirme que para trabajar en una consultora al uso me voy a mi casa. Mi objetivo personal es trabajar poco, ganar mucho y pasarlo bien en el proceso. Si tenemos tanto trabajo que no podemos pararnos a pensar que hacemos bien y como mejorarlo, nunca voy a cumplir mi objetivo. Así que es necesario respirar, y pensar que por dejarnos dos horas en una retrospectiva el mundo no se acaba.
  • En otro orden de cosas, me he hecho runner que está de moda. Ya he corrido hasta 16 kms del tirón, igual llego hasta una media maratón en algún momento, aunque el objetivo no es haces distancia ni carreras, sino estar en forma.
  • Ya había leído que al trabajar con horario flexible el problema es trabajar demasiado, y es verdad. Hay que encontrar el balance entre trabajo y vida personal, por mucho que te guste tu trabajo. Otro objetivo para este año.

Feliz 2015

Mina

Ayer fuimos a cenar al restaurante Mina. No suelo comentar este tipo de cosas por aquí, pero es que fue una experiencia excepcional, tanto en lo culinario (apecto en el que no voy a entrar) como a nivel de trabajo en equipo. Tienen una modalidad de cena que consiste en cenar en la barra del bar, viendo como trabajan en la cocina, que es totalmente abierta. Y la verdad es un placer verles trabajar:

  •  Cero prisas en todo momento. Limitan el aforo del local a 25 comensales, que es el número que han visto que manejan bien, o mejor dicho, muy bien. Calidad sobre cantidad.
  • Esa ausencia de urgencia les permite cuidar el detalle a todos los niveles. Presentación de los platos, explicación de los mismos… Mucho que aprender de como no trabajar demasiado permite a la larga trabajar más y mejor, porque evitas el trabajar dos veces.
  •  Cero indicaciones. Todo el mundo sabe lo que tiene que hacer en todo momento, como mucho se susurran al oído.
  •  Coordinación visual. Tienen un tablero en el que recogen la información de como va cada mesa, lo que han servido… el menu degustación tiene 10 platos, así que más nos vale saber donde vamos en cada momento.
  • Punto extra ver al chef y propietario fregar la cocina al terminar junto con toda la brigada.
  • Colaboración, colaboración, colaboración… todo funciona con un mecanismo bien engrasado, como si estuviera coreografiada toda la actuación.

En resumen, quiero que mi equipo trabaje como estas personas, como Alvaro mismo dice, “no tengo un equipo, tenemos un comando“, un sitio en el que evolucionar y mejorar. Amén.

¿Que voy a hacer mañana? Lo mismo que ayer, seguir trabajando.

Contrastes

Siempre que acudo a una conferencia, evento o socialización con otros profesionales (de mi gremio o de otros), lo que me gusta encontrar son contrastes. Espejos en los que mirarte, para no verte reflejado, o al menos no completamente. Que te devuelvan una imagen nueva de ti mismo, de lo que deberías ser, o al menos tender hacia ello. Que te hagan pensar sobre ti, lo que haces y como lo haces. Que te movilicen, en definitiva.

Estos días encontré un reflejo diferente de mi mismo. Alguien que dejo un trabajo buscando ser más feliz. Me suena un poco. Y evidentemente me vi reflejado, pero distinto. Me obligo a la retrospectiva de tres semanas de trabajo en un minuto. La verdad que que ya la tenía hecha, porque he aterrizado tan de golpe en un campo de batalla donde se libra una guerra feroz, que en principio vamos perdiendo, que se me ha olvidado (un poco) porque vine. Y como terapia voy recordármelo.

Vine a ser más feliz trabajando. Vine a trabajar en un equipo autoorganizado de alto rendimiento. Vine a buscar la excelencia técnica que nos permitiera ser más efectivos desarrollando el software maximice el valor que aportamos al cliente. Vine a enderezar el rumbo de una nave que se estaba desviando, intentado transformar o al menos contribuir en ese cambio hacia equipos autoorganizados intraemprendedores. Vine a ser ágil, con TODO lo que significa.

No vine a una consultora normal, y no quiero estar en una consultora normal. Así que hagámosla especial. Un poco cada día. Empezando hoy.

Gracias, #aos2k14

Salam, agur

No me ha dado tiempo de comentarlo antes (supongo que no ha sido lo suficientemente prioritario), pero hace una semana que he dejado de trabajar para el Ayuntamiento de Vitoria-Gasteiz y he empezado en Init Services, concretamente en el area de salud con InitHealth.

Han sido un montón de años trabajando allí, y me hacía falta un cambio de aires para recuperar un poco la ilusión. Además me apetecía ver cosas nuevas, maneras distintas de trabajar en incluso objetivos nuevos: por ejemplo, hacer producto, que es parte de lo que hacemos ahora.

En todo este tiempo en Vitoria-Gasteiz (además de la costumbre de escribir el nombre completo y oficial de la ciudad) he hecho de casi todo, y he vivido de todo. he trabajado con un grupo de personal estupendas con las que he aprendido muchas cosas, e incluso la gente con la que más he discutido me ha aportado mucho tanto personal como profesionalmente.

En resumen, estoy muy agradecido a toda la gente con la que he tenido la oportunidad de trabajar en este tiempo, y aunque evidentemente dejo la oficina porque quiero, ahora mismo tengo una mezcla de nostalgia e ilusión en el alma. Para toda esa gente mi agradecimiento por todo lo vivido. Salam, agur.

¿TDD ha muerto?

Vaya liada que ha organizado DHH con su entrada, afirmando que TDD ha muerto y tal y cual… Varias personas le han contestado, y la verdad es que la discusión ha tenido momentos con un tono digamos no moderado… He leído ya algunas opiniones (Jorge, Jose) y aquí está la mía.

Hace ya mucho, mucho tiempo que acepté que los equipos (o no equipos, hablo en general) de desarrollo de software son una cosa muy, pero que muy compleja. Que lo que a mi mismo con mi mecanismo me funciona estupendamente, puede que no sea exportable al resto del mundo con facilidad. Es más diría que las personas humanas que desarrollan software son en ellas mismas un sistema muy complejo, y que a mi me gusta esto y me va bien, pero al resto del mundo no… la cuestión es que nos encanta enredarnos en discusiones sin fin en torno a mil temas (IDE, sistema operativo, editor de texto, aplicación para ver pelis…) que simplemente no tienen respuesta correcta. Hace ya muchos años, la verdad es que no recuerdo cuantos, @fxn empezó una keynote en la ya extinta conferencia Rails (escribo esto solo para que anotéis lo mayor que soy) que este tipo de discusiones mejorarían mucho si empezaran así:

“En mi opinión … “

A partir de ahí ya puedes decir lo que sea, que será cierto. Pero pretender que lo mío es la verdad absoluta y que funciona para todos, es, en mi opinión, demasiado presuntuoso.

Así que, en mi opinión, TDD está bien. Me sirve para ir definiendo el software que escribo, incluso cuando lo tengo más o menos claro, además de que como consecuencia tengo una batería de pruebas para ver si sigue funcionando como debe. Aunque también es verdad que a veces algunas pruebas son tal mierda que es mejor borrarlas.  También es verdad que para llegar a este punto me he empeñado bastante, y que no creo que sea especialmente bueno en esta disciplina (más bien bastante malo). Y a veces hay cosas que no sé muy bien como hacerlas con TDD, y no las hago así (pero al menos he pensado un rato sobre el tema).

Por otro lado, he encontrado muchas dificultades para transmitir a los equipos con los que he trabajado que no sólo el TDD, sino las pruebas automáticas son útiles. Así que es un caso claro de que lo que funciona para mí, no siempre funciona para mi equipo, no hablemos de otros equipos en otras empresas en otros paises. Creo que fue @jbrains el que dijo que con los equipos solo se puede bailar, vas para un lado y ves si te siguen, y si no pruebas otra vez (o algo así, no lo recuerdo exactamente🙂 )

* Conste que opino que DHH es un programador excepcional y esta claro que ha hecho una cantidad excepcional de pasta programando. Eso no quita para que a veces se pueda equivocar, o no. Es lo bueno de tener ideas contradictorias, siempre tienes razón.

** He dejado esta entrada en borrador demasiado tiempo y ahora todo el mundo ha escrito sobre el tema: Aquí un resumen con un montón de referencias.

 

 

 

Predictivo Vs Ágil

Escuchando el podcast de Workos.cat sale el tema de si el desarrollo ágil es para todo tipo de proyectos (escúchalo, ellos también tienen su conclusión🙂. Parece evidente que no, si sabes exactamente lo que vas a hacer, como se hace y quién lo va a hacer, lo más razonable es usar una metodología predictiva. El diagrama de Gantt te va a quedar muy chulo, y encima lo vas a clavar (recordemos que sabemos el qué, el como y el quien de pe a pa, por lo que deducir el como es sencillo). No les quito la razón, pero yo opino que…

  • Es muy fácil “creer” que sabemos todo eso, cuando no lo sabemos. De hecho, nos hemos basado en que lo sabemos, o en que podemos averiguarlo rápidamente, durante décadas a la hora de hacer software.
  • Es muy fácil porque los humanos somos especialistas en distorsionar la realidad de distintas maneras: El cliente cree que sabe lo que quiere, el desarrollador cree que le entiende, el que sea que mida todo esto y lo traduzca a dinero cree que conoce la tecnología y lo puede estimar… Pero la realidad es que existen ciertas leyes en la gestión de proyectos software que insistimos en ignorar, y nos hemos dado tortazos contra esta realidad durante mucho tiempo (y aún seguimos).

Por todo esto, si crees que lo sabes todo, adelante, gestión predictiva. Pero asegúrate de saberlo todo, todo, todo.

En muchas ocasiones (2) me he encontrado con gente que ya lo sabía todo o casi todo. En la mayoría de los casos, programadores, desarrolladores, analistas o lo que seamos, que sabían más que el usuario, que se equivocan nunca o casi nunca, que hacen notar los errores ajenos más que los propios… y a los que el desarrollo ágil les parece ineficiente, “por que ya sabemos como hacerlo” (y más cosas, pero el tema es el que es). Siempre les digo lo mismo: si estamos seguros, es mucho más eficiente la gestión predictiva. Siempre pasa lo mismo (las dos veces que me ha pasado), seguimos igual, tan seguros no estaríamos.

2013

Acabo el año revisándolo a nivel global. Teniendo en cuenta algunos objetivos marcados, el 2013 ha sido el año en el que:

  • No he recaído de mis dolencias físicas. Un diez en eso, me encuentro estupendo.
  • He participado activamente en la organización de la CAS 2013, y no ha ido mal. Siempre hay margen de mejora, pero en general la sensación es buena.
  • Esto se ha llevado una gran parte de mi energía este año, así que no he hecho gran cosa en otros ámbitos.
  • He estado (por destacar algo) en la Software CrapmanShit de Barcelona. Soy efectivamente más crap&shit que CraftmanShip, pero aún así un montón de gente interesante y buenos ratos, y mucho material para pensar…
  • A nivel laboral, hacemos progresos pero muuuuuuuuy despacio. Si tengo una oportunidad en otro sitio, me gustaría aprovecharla, porque creo que me hace falta un cambio de aires, mucho tiempo para ser saludable en la administración (quizá demasiado para ser recuperable para la vida moderna).

Para este 2014 quiero:

  • ACLARARME, que tengo mucho lío.
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.