Por todos lados dicen que un programador muy bueno puede ser hasta 10 veces más productivo que uno malo...
Yo creo que la relación no es exactamente así sino que uno bueno puede ser dos o tres veces más productivo que uno normal y uno malo, en realidad no es que tenga una productividad muy baja o nula, sino que genera más deuda técnica y problemas del valor que aporta (código de muy mala calidad, muchos bugs, diseños malos y no entendibles).
Normalmente no nos atrevemos a decirlo, pero hay gente que no la quieres en tu equipo ni aunque vengan con un supuesto "coste cero". En estos casos, realmente prefieres que esté parado y sin tocar un teclado. Por lo menos que no haga el mal.
Es un generador de deuda técnica...
Por eso es tan importante conseguir crear un buen equipo que trabaje coordinado y con una visión común. En estos casos cualquier problema de generación sistemática de deuda técnica se detectaría de inmediato y se podría solventar.
Por cierto que los humanos solemos ser muy malos evaluandonos a nosotros mismos (ya sabes, aquello de que el 90% piensa que conduce mejor que la media)... :-)
Sunday, June 28, 2015
Wednesday, June 24, 2015
AOS 2015 Gijón
Este fin de semana pasado se ha celebrado el AOS2015 en Gijón. El AOS (Agile Open Space) es un evento organizado por Agile Spain y reúne gran parte de la comunidad ágil nacional para compartir experiencias durante un par de días.
El formato usado es Open Space que es una conferencia auto organizada por los propios asistentes en el mismo momento del evento.
En esta ocasión he tenido la suerte de compartir la experiencia con gran parte del equipo de producto de Alea Soluciones. Sólo nos ha faltado dos personas para ir el equipo completo. Quizás el año que viene podamos ir todos.
Como siempre, vengo enchufado, con nuevas ideas y lleno de energía. Además tal y como hemos comentado dentro del equipo, esta sensación es compartida, por lo que es un fantástico momento para realizar experimentos en la forma de trabajar como equipo y continuar con nuestro proceso de mejora continua.
Por aquí dejo algunas notas y reflexiones de las sesiones a las que asistí durante el evento (no me acuerdo muy bien del nombre de algunas de las sesiones):
- Creo que era Money Driven Development, o algo así. (Marc Florit) Esta sesión me gusto bastante y me quede con algunas ideas para experimentar dentro del equipo y de la empresa. Se hablo de autoorganización, modelos de recompensa, motivación, escalado de la autogestión para temas como la retribución. Salieron modelos como el de Semco, el tema de cooperativas liquidas, Morning Star, etc
- Desescalado Radical (Jorge Uriarte) Creo que esta es la sesión que más me aporto. Llevo ya un par de años intentando limitar de forma sistemática y consciente la cantidad de trabajo realizado, intentando centrarme mucho en cómo maximizar la cantidad de trabajo no realizado. Esta sesión trataba exactamente de eso. Jorge comentaba como acostumbrarse y acostumbrar al cliente a necesitar lo mínimo, dedicar mucho esfuerzo a tener un cliente y un equipo focalizado en lo esencial. También hablaba del roadmap con rutas de escape, cruces y decisiones (a tomar en el último momento responsable) (al estilo de Gojko Adzic). Me quedo con la idea de implantar dentro del backlog una zona limbo y limitar el backlog de una forma radical (total, si algo es importante, volverá a aparecer). Software como inventario a limitar y con un coste basal importante.
- Ship it Motherfucker (@mikelodeon) Muy centrada en el pipeline de entrega de valor que tienen montado en beBanjo y como se centraban en aportar valor real al cliente en vez de en seguir un proceso "agile" de libro. Mi opinión lo que describió es precisamente un proceso ágil de libro, es decir, un proceso ligero (lean), centrado en aportar valor real al cliente a un ritmo sostenible en el tiempo y basado en una cultura de excelencia técnica y de motivación del equipo. Como ya he comentado en alguna ocasión yo considero que la agilidad tiene dos pilares principales, la cultura y las prácticas técnicas, y el proceso que presentaron era precisamente eso. Me quedo con lo bien implementado que tenían el flujo kanban y como todo el proceso se había optimizado de forma global para maximizar el flujo. Además siempre tiraban de los items desde el final del tablón (es decir desde la puesta en producción), vamos, un sistema completamente pull. También me resulto curioso que habían abandonado el Pair Programming por la fricción que se generaba al intentarlo hacer en remoto.
- Finanzas personales ágiles (@mikelodeon) Fue interesante ver cómo se organizaba en este sentido. Actualmente en mi familia estamos introduciendo algunas prácticas ágiles (tablón kanban y retrospectivas) y creo que nos va ha venir muy bien algunas de las cosas que se comentaron en esta sesión.
- Enseñando a Programar (@devscola y senpaidevs) Esta sesión me pareció muy interesante aunque no sea algo que vaya a utilizar a corto plazo. En cualquier caso es un tema que me interesa y en el que veo mucho esfuerzo por parte de la comunidad, así que salí contento.
- Equipos autorganizados SI… pero en equipos (https://twitter.com/xav1uzz). Supongo que el mensaje era cuestionarse todo, incluido la organización en equipos, pero no llegue a pillarle el punto.
- Aterrizaje de proyectos (@ujue) Me pareció una mezcla fantástica entre la inception y otra serie de prácticas. Me gusto bastante, lo que no tengo muy claro es si sabre aplicar muchas de las cosas que comento. En cualquier caso, seguro que algo de poso dejó :)
Además, propuse algunas otras sesiones y colaboré en otras que no había propuesto yo, pero que por distintos motivos me interesaban.
- el eXPerimento (yo mismo @eferro) Explicamos como llevamos más de dos años haciendo Extreme Programming y como hasta ahora estamos muy satisfechos con esa forma de hacer las cosas. Se intentaba transmitir:
- que es posible hacer XP
- la velocidad es muy buena pero que necesitas superar la barrera de entrada inicial (por ejemplo contratando o trabajando con expertos)
- hay que centrarse en aportar valor de forma completa, por lo que tiene todo el sentido hacerlo todo, desde hablar con el cliente hasta conseguir tenerlo en producción y que lo usen (eso incluye sistemas, desarrollo, etc... full stack de verdad :) )
- que el desarrollo ágil de software es completamente imposible a medio largo plazo sin prácticas técnicas como las que te da XP (ver los dos pilares del desarrollo ágil).
- Sesión de Diseño con DDD (@carlospeix) Se uso un ejemplo del grupo de ddd-es para iniciar una conversación sobre el posible diseño de un pequeño modelo. Aunque fue interesante no estoy muy conforme con el resultado, puesto que el ejemplo hizo que nos centrásemos en el modelado estático (entidades y relaciones) del sistema y creo que eso es MUY peligroso (ver Verbos vs Nombres). Espero que por lo menos se transmitiese bien que hay que centrarse en el uso de un lenguaje ubicuo y que ese lenguaje debe ser el usado por los expertos de negocio y no ese lenguaje técnico que solemos obligarles a usar (CRUD, tablas, transacciones, etc...). También espero que quedase claro que casi lo más importante es el concepto de bounded contexts puesto que sin eso DDD se puede convertir en una disculpa para hacer sesiones interminables de modelado (al más puro estilo diseño upfront de todas la vida).
- El Rol del Product Owner (@AlbertodlCG y ??) Me acerque a esta sesión para echar una mano a @AlbertodlCG puesto que es nuestro Producto Owner / Product Champion y aun siendo su primer AOS le echo narices para presentar una sesión (bravo!!!). El caso es que al final se apaño muy bien así que simplemente me quede para disfrutar de la sesión. Me quedo con tres cosas:
- resulta más complicada la comunicación con los stake holders que con el equipo de desarrollo (al contrario de lo que yo suponía).
- cuesta mucho hacer historias de usuario que realmente aporten valor extremo a extremo (mucha gente seguía haciendo historias de usuario del tipo "login", lo que impide hacer historias independientes que entreguen valor).
- me quede con la sensación de que muchos de los product owners allí presentes no estaban muy integrados en el equipo y estaban en una situación que no les permitía centrarse en el producto. Por suerte para nosotros nuestra situación es muy distinta.
También fue interesante la conversación con @francholab y Apa sobre Retrospectivas en equipos distribuidos de la que me llevo alguna idea de dinámica como la de la retro en silencio (y sólo por chat).
Conclusiones del estado de la comunidad ágil
A veces creo que se nos olvida un poco que la parte principal o al menos la original es entregar valor mediante software, creo que no es lo único, pero si lo central.Se tiende a pensar que sin prácticas técnicas y sin ser profesionales en el desarrollo se puede aportar valor de forma sostenida, pero mi opinión es justo la contraria. Si no tienes ni idea, lo más que conseguirás, incluso siguiendo todos los principios, es exponer ese desconocimiento rápidamente y de forma transparente, que no es poco, pero que no te librará de hacer un producto/proyecto de mierda (agilidad no es una receta para el éxito). Esto está muy alineado con la sesión de Scrot presentada por los maños (@dani_latorre y @nestorsalceda) :-)
Por cierto que hemos aprovechado el AOS para conseguir nuestra certificación de equipo Scrot :-)
Me voy con la pena de ver que no hay mucha gente (porcentualmente al número de asistentes) haciendo Extreme Programming. Creo que eso nos impide avanzar como comunidad y que hace que la agilidad para el desarrollo de software muchas veces se quede en buenas intenciones (sesiones sobre el Fracaso Agile, Scrot, etc...).
Conclusiones, retro, organización
Con respecto a la organización y al evento en si, tengo que decir que le doy un 9, me encanto....Para conseguir el 10 hubiésemos necesitado más espacios sin sillas, más diáfanos y planos, para facilitar el debate.
En la retro comente que quizás con menos tracks podría generarse más debate o más mezcla en las sesiones. La verdad es que pensándolo ahora creo que no tiene sentido... Para eso un open space es auto organizado y ya tiene reglas para facilitar la mezcla de asistentes.
Muy buena idea la del photocall, me ha permitido sacarme unas cuantas fotos y pasármelo pipa viéndolas con mi peque de tres años :)
También nos hemos podido sacar alguna foto de equipo que está para enmarcar.
Además como soy de Bilbao, todo el entorno me hacia sentirme como en casa, así que este AOS puntúa doble.
Felicitaciones a la organización, lo habéis hecho de 10. Muchas gracias!!!!
Monday, June 08, 2015
More interesting Podcasts/Talks
It took me long time, but these are the most interesting talks I saw/heard the last month:
I'll try to rescue the frenquency of this kind of posts :-)
- Succeeding with TDD: Pragmatic Techniques for effective mocking Venkat Subramaniam. Some simple techniques that can help us be quite effective with mocking
- Radical Ideas from the Practice of Cloud Computing
- SE Radio Episode 221: Jez Humble on Continuous Delivery
- Simple Made Easy 2011 Rich Hickey. Great talk and a good excuse to study functional programming.
- Design and architecture for actors Lambda Jam 2014 - Martin Logan A reference talk about the design for concurrency using the actor model.
- Embracing Uncertainty Dan North Keynote. I show this this key note several times but I allways find new interesting details.
- Agile - You keep using that word Dan North Insparing key note
- Evolutionary Architecture and Microservices - A Match Enabled by Continuous Delivery Rebecca Parsons
- http://www.agilealliance.org/resources/learning-center/strategies-for-agile-portfolio-management Goods advice to prioritize, focus on value and portfolio management strategies.
- Pivotal - 3 Big Shifts: CloudFoundry & the future of enterprise IT James Watters Very insterestink talk about the cloud revolution, orchestration. It present the most disruptive techs for the cloud (OSS as a tech standard, software designed as cloud native and agile transformation (dev and ops))
I'll try to rescue the frenquency of this kind of posts :-)
Tuesday, May 26, 2015
Aplicación del principio DRY
Desde siempre he tenido claro que en desarrollo es muy importante que cada concepto este una sola parte del sistema. Por otro lado, también tengo muy presente que la duplicidad de código es un problema y que hay que intentar limitarla y en los casos que sea necesario (casi todos) eliminarla sistemáticamente.
Muchas veces se sigue el concepto DRY a ciegas, sin tener en cuenta que cada decisión tiene un coste, por lo que voy a exponer algunos puntos que pueden ayudar a decidir cuando debemos eliminar la duplicación y cuando podemos vivir con ella.
- Debemos diferenciar duplicación en conceptos de negocio, reglas, validaciones, flujos, etc y duplicación a nivel de implementación y código donde se pueden dar pequeñas duplicidades.
- La duplicidad en conceptos de negocio se debe minimizar todo lo posible.
- La duplicidad a nivel de código, puede ser una pista de que hay una abstracción pidiendo ser descubierta, un comportamiento emergente del sistema o simplemente un patrón propio de nuestra aplicación. Es importante minimizarla, pero no es un drama si existe algo de duplicidad. Eso si, hay que tener mucho cuidado de no generar una abstracción prematura. En mi experiencia las abstracciones prematuras son mucho peores que la duplicidad.
- Si haces TDD lo mejor es duplicar el código para conseguir verde y una vez en verde y bien cubierto por los tests, refactorizar eliminando la duplicación.
- Dependiendo del lenguaje hay duplicidades que tienen un coste elevado de eliminación o que no tienen una solución idiomática en ese lenguaje. En esos casos debemos quitar la duplicidad, si el resultado es más sencillo de entender (no solo por ti, sino por todo el equipo). Ante la duda, debe primar siempre la legibilidad.
- Es importante saber que cuando eliminamos una duplicidad normalmente lo hacemos creando una clase común, una biblioteca, un método o cualquier otro artefacto que nos permite referenciarlo/usarlo desde varias partes de nuestro código. Esto es una dependencia entre el código cliente y el código a reusado. La dependencia es una de las relaciones más fuertes que se puede dar en el código y siempre es un coste importante así que hay que tener en cuenta este punto a la hora de evaluar si eliminamos la duplicidad o no.
- Siempre debemos dependender de artefactos que sean más estables que nosotros mismos, es decir si hemos sacado código común a una biblioteca, pero el api de esta biblioteca cambia constantemente es un indicador de que no hemos realizado una buena abstracción y que el coste de mantemiento se nos va a disparar.
Resumiendo:
- Es importante no tener duplicidad de conceptos de negocio (la duplicidad de bajo nivel es menos importante).
- Evaluar peligro de abstracción prematura.
- Evaluar coste añadir dependencia vs ventaja de eliminar duplicidad.
- Si al eliminar duplicidad se pierde legibilidad, lo estamos haciendo mal.
- Mejor seguir un proceso de usar, usar, reusar, abstraer (no ir directamente a generar una abstracción).
Si no te puedes permitir esperar un poco antes de hacer una abstracción o una vez que la haces, no te sientes capaz de eliminarla o modificarla en caso de que no se ajuste correctamente a lo que se necesita, tu problema es que estás generando deuda técnica mucho más compleja que la que generas por dejar una pequeña duplicidad.
Aunque el principio DRY puede parecer sencillo de entender, su aplicación, como siempre en el desarrollo de software, no es sencilla ni sistemática.
Thursday, April 23, 2015
Presentación Golang design4concurrency GoMad Abril 2015
El código de ejemplo, las diapositivas y un mind map inicial se puede encontrar en:
Y las referencias usadas son:
- Go concurrency patterns concurrency
- Advanced Go concurrency patterns advanced-go-concurrency-patterns
- Designing for Actor Based Systems designing-for-actor-based-systems
- Golang patterns for serving on-demand, generated content patterns-for-serving-on-demand-generated-content
El mensaje que queremos transmitir es:
- Debemos diseñar para la concurrencia desde el principio (centrándonos en identificar las actividades concurrentes y sus dependencias) (Ver verbos vs nombres y designing-for-actor-based-systems)
- Cada pequeña parte del estado de la aplicación tiene un solo propietario y no se debe compartir.
- Como opción por defecto se deben usar tantas goroutinas como actividades concurrentes (son gratis)
Creo que lo conseguimos transmitir sobre todo con los ejemplos de diseño. Los ejemplos de código nos podían haber quedado mejor... pero creo que el mensaje está transmitido :-)
Wednesday, March 25, 2015
Opinión sobre la tecnología en educación primaria/secundaria
![]() |
| By OLPC Foundation [CC BY 2.5 (http://creativecommons.org/licenses/by/2.5)] via Wikimedia Commons |
En el podcast sobre agilidad, rantpod, dedicaron un capitulo la tecnología y su uso en el entorno educativo
Como orgulloso padre de una peque de tres años, es un tema que me interesa, asi que les deje el siguiente comentario en la web del podcast:
Lo primero a tener en cuenta es que solemos considerar tecnología o nueva tecnología a todo aquello que no estaba cuando nacimos, así que lo que para los profesores o padres es nueva tecnología, puede que para el niño no lo sea. Sobre todo teniendo en cuenta que seguramente le pusieron canciones en la móvil o veía sus dibujos animados preferidos en youtube. Para el niño un ordenador/tablet/móvil puede ser tan común como una pintura o un libro.
En cuanto al si introducir la programación o la robótica en edades tempranas, yo diría, que hay que transmitir a los niños al menos lo necesario para que puedan distinguirlo de la magia, puesto que ya es parte de su día a día.
Si no son capaces de distinguirlo de la magia, ya nos podemos olvidar del pensamiento crítico.
No hay más que ver el efecto que tiene que no tengamos ni idea de biología, química y otras ciencias... para empezar es la base de la que se aprovechan las pseudociencias.
No se qué opináis al respecto, pero como padre, le doy muchas vueltas a estas cosas y esas son las principales conclusiones a las que he llegado :-)
Me encantaría leer más opiniones al respecto.
Subscribe to:
Comments (Atom)








