- Stroop, Whorf, And Elixir Dave Thomas. Interesting info about how the language we use shape our thinking process and the importance of learning very diferent programming languages.
- Why Everyone Needs DevOps Now: A Fourteen Year Study Of High Performing IT Organizations Gene Kim. Interesting examples about high performing IT organizations (importance of development + operations, continuous deployment, flow center process, etc).
- Testing the Hard Stuff and Staying Sane John Hughes A good aproximation to automatic check/testing for concurrent stuff (QuickChecks). Examples with the erlang version.
- Evolutionary Architecture and Microservices Rebecca Parsons.Informative talk about microservices and the Continuous Delivery as the central practice that allow the constant evolution of the apps and real agile development.
- Building Event-Driven Microservices with Scala, Functional Domain Models and Spring Boot Chris Richardson. A interesting and practical example of to create small independent services with event sourcing and CQRS. A Good explanation.
Friday, September 18, 2015
Podcasts/talks. Emptying the queue (II)
I continue empting the talks queue... Here is another small batch of interesting talks:
Sunday, September 06, 2015
Coste basal del software vs capacidad infinita
En mi opinión, el coste de desarrollo por cada grupo de funcionalidades se puede dividir de la siguiente forma:
- Coste inicial de desarrollo
- Coste de existencia (coste basal):
- Coste de existencia / complejidad añadida
- Coste de existencia para otras funcionalidades
Coste inicial de desarrollo
Este es el coste/gasto en el que incurre el equipo durante el desarrollo inicial de la funcionalidad. Incluye desde que el equipo comienza a trabajar en la funcionalidad o grupo de funcionalidades hasta que el cliente la tiene disponible y comienza a usarla. Por supuesto este proceso debería incluir múltiples puestas en producción para ir obteniendo feedback y realizando los ajustes necesarios...A partir de este momento, comienzan a producirse de forma continua y hasta el final de la vida de la funcionalidad o del producto, un coste de existencia o coste basal.
Coste de existencia o Coste basal
Este coste, continuado en el tiempo y que solo termina con la retirada de la funcionalidad o el fin de la vida del producto, es el coste en el que incurre el equipo por la existencia de ese código y esa funcionalidad en el producto.Es importante tener en cuenta que este coste no se refiere al coste de realizar modificaciones a la funcionalidad o corregir errores, se refiere al coste que conlleva simplemente que el código esté ahí...
¿Por qué se produce este coste?
- El equipo tiene que conocer ese código (dónde está, qué dependencias tiene, con quien interactua, cómo está escrito...)
- El conocimiento y técnicas del equipo están en continua evolución. Cuando el equipo mejora en alguno de estos aspectos tiene que decidir si actualiza el código de la funcionalidad, si lo hace es un coste, si no lo hace, también puesto que será diferente que el resto de código de que dispone.
- Cuando aparezcan nuevas funcionalidades se debe ver dónde impactan y no es lo mismo tener que identificar esos impacto en una aplicación de un tamaño X que en una de un tamaño X más el tamaño de la funcionalidad.
- Lo mismo pasa cuando entra un nuevo miembro del equipo y tiene que conocer la base de código que existe.
Y lo peor de todo es que este gastos es continuo hasta la "muerte" de la funcionalidad, es decir el fin de vida del producto, hasta que no la use ningún usuario o hasta el fin del mundo (lo que sea que ocurra antes).
Además, si se sobrepasa el punto de obsolescencia tecnológica (versión de lenguaje obsoleto, dependencias que desaparecen, etc) antes de la "muerte" de la funcionalidad el coste de mantenimiento se dispara y podemos entrar en una situación en que la capacidad del equipo quede ocupada al completo intentando mantener bajo control funcionalidades que ya han pasado el punto de obsolescencia tecnológica.
En mi experiencia, siempre me he encontrado que este coste se obvia y tanto los desarrolladores como los clientes y managers simulan que no existe, tomando decisiones (sin sentido) que no lo tienen en cuenta.
Capacidad no infinita
El problema es que la capacidad de un equipo de desarrollo no es infinita y aunque cambia (en positivo o negativo) con el tiempo debido a distintos factores (el conocimiento del negocio, de las técnicas...), existe una tendencia clara a que la capacidad usada en el coste basal de las funcionalidades ya hechas vaya mermando la capacidad disponible para nuevas funcionalidades. |
| Coste acumulado |
Si el equipo desarrolla sin usar buenas prácticas y sin alta calidad, este colapso es prácticamente inmediato en el caso de tener muchos bugs o en unos pocos meses cuando aún no teniendo muchos bugs la calidad interna del software es baja.
Si el equipo es bastante bueno y se preocupa por la calidad esta tendencia será muchísimo menos pronunciada y se podría tener una capacidad "razonable" para nuevas funcionalidades durante años, pero por supuesto poco a poco iría disminuyendo y a la larga desaparecería.
A lo largo de los años las estrategias que he visto para lidiar con este problema son:
- Ignorarlo y esperar al colapso.
- Hacer crecer de forma constante tu equipo para mantener una capacidad para nuevas funcionalidades constante (este enfoque es el que parecen tener empresas de tecnología puntera que crecen en ingenieros de forma constante; google, amazon, netflix, spotify ...)
- Crear equipos de mantenimiento a los que pasar el producto despues del desarrollo inicial (por supuesto esto es similar al punto anterior).
Claramente este problema sólo afecta a los departamentos de desarrollo interno o a los equipos de desarrollo dedicados a producto. Para el caso de consultoras o equipos que trabajan en proyectos este tipo de problema no les afecta puesto que pasado el desarrollo inicial se suele entregar el proyecto y el mantenimiento es problema del cliente.
La solución
Y ahora viene cuando planteo la solución que he encontrado....
Pues no, no tengo ni idea de cómo solventarlo, como mucho se retrasar las consecuencias del problema, minimizarlo, pero no solventarlo.
Me encantaría opiniones sobre como tratar a medio largo plazo este problema. Lo único que se me ocurre es el crecimiento continuo de equipo o tener una política de "end of life" de los productos muy agresiva.
Se aceptan sugerencias, experimentos, opiniones, cualquier comentario será bienvenido.
Tuesday, August 18, 2015
Podcasts/talks. Emptying the queue (I)
I have a long queue of interesting talks, so I'll post the talks links in small batches. Here come the first one.
Interesting Agile/Lean related talks:
Interesting Agile/Lean related talks:
- Competing On The Basis Of Speed (Mary Poppendieck) Optimizing for speed, flow, and waste reduction. Lean Software Development
- The role of leadership in software development (Mary Poppendieck) Good talk, full of good advices.
- The Power of an Agile Mindset (Linda Rising) Very good talk about the "Agile" mindset (aka experimentation or growth mindset)
- Experimentation Mindset (Michael Norton) Acomplement for the Linda Rising talks. Continious learning, experimentation Mindset, double loop learning, ...
- Curing Agile Hangover with Craftsmanship (Sandro Mancuso/Masook Badar) Story about the real agile process of continuous improvement, professionalism. No more "scrum but" agile :)
- The Nature of Software Development (Chet Hendrickson / Ron Jeffries) Interesting talk with the same subject/ideas described in the Ron's book (with the same tittle). Current state of Agile and Agile's good ideas in a real context of common Agile misunderstandings.
- Protocols - The Glue for Applications (Torben Hoffmann) Very interesting, distributed systems, fault tolerant and the desing process for this kinds of systems (full of advices from the Erlang community).
- Keys to SRE (SREcon14) (Ben Treynor) Good description about the term/role of SRE (from the google perspective).
When I empty the talks queue, I'll try the generate this kind of entries more often...
Saturday, July 18, 2015
Ultimo post de la PiWeek VIII
Algunos equipos controlan mejor que otros los nervios y son capaces de trabajar en el proyecto hasta el último minuto, yo no soy de esos y siempre prefiero trabajar con margen y dejar las cosas cerradas el día anterior.
Durante un rato estuve preparando la demo, aunque no había demasiado que hacer.
Luego comente las notas que tenia del libro ClojureScript Unraveled e incluso creo que Andrey ya comenzó a hacer ciertos cambios a partir de ese feedback.
Espero que David me tenga informado de si alguna de las cosas les ha ayudado a mejorar :-)
Sobre la una de la tarde llego el climax de la PiWeek... las presentaciones... como en otras ediciones, las siguientes dos horas y media fueron de presentaciones de unos 10 minutos por proyecto.
El ambiente fue de completa fiesta y de asombro por la calidad de todos los proyectos.
Hay que tener en cuenta, que no hablamos de presentaciones powerpoint o equivalente... hablamos de código funcionando o diseños, algo real, palpable, nada de documentos de buenas intenciones...
Todos los proyectos tienen un nivel impresionante, pero lo que más me ha impresionado es el proyecto uxbox, realizado en clojure script. Además de lo bien y fluido que queda el interfaz de usuario, la velocidad de desarrollo que han tenido ha sido impresionante, sobre todo teniendo en cuenta que varios de los miembros del equipo eran la primera vez que trabajaban con ese lenguaje.
Como otras veces, me he quedado impresionado por todo lo que tiene que ver con Frontend, UX, diseño y similar. Toda mi experiencia ha estado siempre centrada en software que no ha requerido parte visual importante (sistemas industriales, backends, telecomunicaciones, retail, ...) así que siempre alucino con los proyectos de la piweek (se nota la experiencia acumulada en software muy visual). En especial en estos temas, me han impresionado Guild Empire, Zombie Time!, Baoqu, Mineralis, etc..
Cada PiWeek es distinta y en cada edición consigues más o menos avances personales, noto que esta edición, junto con la primera a la que asistí, son las que más han aportado a mi avance personal como desarrollador.
Así que otra edición más, reto conseguido...
Referencias:
PiWeek edición VIII (Cuarto Día)
Aunque lo escribo con retraso, este post corresponde al cuarto día (jueves) de esta edición de la piweek.
En el proyecto eventsview avanzamos hasta dejar una versión usable con búsqueda y los filtros activados. Estoy bastante contento, por que aunque no es nada vistoso nos va a valer como base para desarrollos que tenemos que hacer en Alea y que poco a poco voy cogiendo flujo en javascript y en la parte web. Hay que tener en cuenta que en mi día a día no suelo tocar para nada web, por lo que sólo puedo avanzar en este tipo de cosas con proyectos personales, así que algo como la piweek para mi es un "acelerador" para mi aprendizaje.
Una vez más, los consejos sobre usabilidad que nos ha dado Esther han servido para hacer la interacción con el usuario mucho más sencilla.
En cuanto a expects ya conseguimos tener todos los tests en verde y Jaime se encargo de generar una nueva versión release candidate y de actualizar doublex-expects que depende de expects.
Expects 0.8.0rc1 is out with new and more descriptive failure messages https://t.co/bZXAzFW9Sy #piweek #tdd #bdd #python #testing cc @eferro
— Jaime Gil de Sagredo (@jaimegil) July 17, 2015
Como mis objetivos para la PiWeek eran darle un empujón a mi aprendizaje de javascript, disponer de una base para desarrollar un visualizador de eventos y ayudar a Jaime a generar una nueva versión de expects, la verdad es que para el jueves a media mañana los objetivos estaban cumplidos...El truco como siempre es tener unas expectativas bajas y gestionarlas bien ;-)
El caso es que a partir de ese momento me dedique a investigar cosas que me parece que a medio plazo pueden resultar muy interesantes.
Entre otras cosas estuve trasteando con react y creo que puede tener su sitio para crear partes del frontend reusables para la arquitectura de servicios que estamos desarrollando en Alea Soluciones.
También curiosee con clojurescript y la verdad es que me pareció impresionante las cosas que se pueden conseguir. En este caso, creo que si ahora mismo quieres aprender algo sobre clojurescript, tu sitio es la oficina de kaleidos.
En concreto repase un capitulo del libro de Andrey Antukh y Alejandro Gomez, ClojureScript Unraveled y tome algunas notas para poder enviarles feedback y pequeñas correcciones.
También trastee con ayuda de Alonso hasta tener una versión de clojurescript decente en mi equipo. Podéis ver las notas de la instalación en https://github.com/eferro/clojurescriptnotes
Me quede bastante impresionado con cómo se puede trabajar con el entorno creado usando https://github.com/bhauman/figwheel-template para crear un proyecto. En concreto el flujo de desarrollo en un proyecto con reagent parece de lo más interesante y el proyecto uxbox de la PiWeek así parece confirmarlo.
Desde luego, para la tarde del jueves ya estaba completamente Agotado!!!! el ritmo de piweek es bastante demoledor.
Referencias:
- http://piweek.tumblr.com/
- http://www.piweek.com/
- http://www.kaleidos.net/
- hashtag piweek
- https://github.com/bhauman/figwheel-template
- ClojureScript Unraveled
- Clojurescript
Wednesday, July 15, 2015
PiWeek edición VIII (tercer día)
Ya estamos en el ecuador de la piweek y parece que todos los proyectos están muy encarrilados... Como siempre se ve un nivel espectacular y además de las cosas en las que estoy metido, suelo intentar curiosear, sobre todo en los proyectos realizados con clojurescript, que tienen muy buena pinta...
Tengo pendiente darle un empujón fuerte a ClojureScript Unraveled el fantástico libro que están escribiendo sobre clojurescript Andrey Antukh y Alejandro Gomez
Me he comprometido con Andrey a leer y dar feedback de la parte de instalación y tooling para ver si es adecuado para alguien que no tenga ni idea (como yo :-) )
Así que mañana le dedicaré unos cuantos pomodoros.
En cuanto a los dos proyectos en los que estoy metido con Jaime, la verdad es que vamos avanzando a buen ritmo.
Eduardo - Piweek from kaleidos on Vimeo.
Con expect ya volvemos a estar en verde después del cambio de diseño para mejorar los mensajes de error :-) (hacia tiempo que no pasaba tanto tiempo con los tests rotos)
En cuanto al visor de eventos, hoy hemos metido gran cantidad de eventos medio reales y hemos realizado las adaptaciones para comenzar con el filtrado. En este caso el avance es mucho más lento, pero como el objetivo en mi caso es aprender javascript y no tanto el resultado final, pues estoy bastante contento.
Una vez más, Esther Moreno nos ha echado una mano con el UX, ayudandonos a aclarar las ideas.
Además, me he aprovechado de estar rodeado de mucho conocimiento para hacer preguntas de novato de javascript y del entorno.
En concreto, creo que era la única persona en el planeta tierra que no sabia que se podia poner un punto de ruptura para arrancar el debugger en el chrome con solo poner "debugger;"
Gracias Alonso, solo por ese detalle puede que ya tenga amortizada la piweek!!!
El que no se divierte en la piweek es por que no quiere.
Referencias:
Subscribe to:
Posts (Atom)