tag:blogger.com,1999:blog-372512672024-03-19T05:23:15.378+01:00eferro's random stuffEduardo Ferro Aldama (eferro) personal blog...
Expanding my comfort zone. Agile mindset. Software Developer #Python #Go #FLOSS #agile #extremeprogramming https://github.com/eferro https://linktr.ee/eferro
Development, Agile, Software Crafter, and random tech and nontech stuff.
Opinions are my own.
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.comBlogger555125tag:blogger.com,1999:blog-37251267.post-14293938957090667332024-03-12T09:57:00.002+01:002024-03-12T09:58:47.054+01:00Disfrutando y aprendiendo en el SOSZ24<p>Este fin de semana he asistido un año más al <a href="https://sosz.cachirulovalley.com/">Startup Open Space Zaragoza</a>. Como siempre que voy, he vuelto con las pilas cargadas, con muchas ideas y con una genial sensación de haber compartido el fin de semana con una gran comunidad. Es imposible transmitir cómo es un <a href="https://en.wikipedia.org/wiki/Open_space_technology">Open Space</a> de este nivel si no has asistido a uno. Solo puedo decir que el <a href="https://en.wikipedia.org/wiki/Open_space_technology">Open Space</a> es el formato que más me gusta y que el <a href="https://sosz.cachirulovalley.com/">SOSZ</a> es, de largo, de lo mejor que tenemos para cualquier persona interesada en el mundo de las startups, los productos digitales y la tecnología.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2mJV2q7ggJ4FlF3ye2kNfn6ygZoajRvl4zxMhAW3XTe2zcJHQhkQSvczwMSsVm4aHy72Db6s_zmNeoDKlgOSD8RMgSW67Bydj-Ma4MwduFUoHVJbNS3YnkFuJ-JzyB5x9lHIbmIENOrCiGbDFBeNRhYVKRIvJ-3KG3LQL0iN7o_cTuR2JRDmB/s2991/sosz.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1987" data-original-width="2991" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2mJV2q7ggJ4FlF3ye2kNfn6ygZoajRvl4zxMhAW3XTe2zcJHQhkQSvczwMSsVm4aHy72Db6s_zmNeoDKlgOSD8RMgSW67Bydj-Ma4MwduFUoHVJbNS3YnkFuJ-JzyB5x9lHIbmIENOrCiGbDFBeNRhYVKRIvJ-3KG3LQL0iN7o_cTuR2JRDmB/s320/sosz.jpeg" width="320" /></a></div><p>Dado que el formato es <a href="https://en.wikipedia.org/wiki/Open_space_technology">Open Space</a>, la agenda se va construyendo en el momento por los asistentes. Aunque se propusieron muchas sesiones, no pude asistir a todas las que me hubiera gustado. Aún así, aquí tienes un resumen de las sesiones a las que asistí:</p><p><br /></p><p></p><ul style="text-align: left;"><li><b>"Cómo mantener motivado a un equipo en tiempos revueltos"</b>. Se generó un debate interesante sobre el tema. Se trataron cosas como la infantilización del sector, la evolución de los últimos años en el sector, la importancia de la comunicación y la transparencia en tiempos revueltos.</li><li><b>"Modelos salariales / ¿cómo va lo de la pasta en las self-orgs?"</b>. Me gustó ver que, aunque no es muy común en España, hay empresas que están experimentando con modelos salariales diferentes. También se habló de cómo estructurar la compensación en empresas algo más clásicas y que están creciendo, por lo que se están planteando cambiar su modelo salarial. Se habló de cómo dividir la compensación entre salario base, variable y bono. Me resultó muy interesante, aunque mi tendencia es intentar siempre evitar los bonos, sobre todo si son individuales. Pero entiendo que es una práctica muy común.</li><li><b>"Hacer producto sin código"</b>. De esta sesión me quedo con cómo han orientado en codely.tv el desarrollo de las partes no core mediante el uso de plataformas no/low-code integradas con servicios SaaS. Me interesó en especial la aproximación que tienen al testing para estos casos, puesto que este tipo de plataformas no suelen favorecer el testing adecuado. Me he apuntado para probar la solución que están usando ellos, puesto que yo uso otra distinta y la verdad es que tengo el testing muy olvidado en esa parte :)</li><li><b>"Back from the Cloud"</b>. Este debate fue interesante porque pudimos ver cómo se ha ido evolucionando en el uso de la nube y cómo, en algunos casos, algunas empresas están empezando a plantearse salir de la nube por coste, de la misma forma que subieron a ella por el mismo motivo. Al final, como siempre, se trata de contexto y de entender las herramientas que tenemos a nuestra disposición. Me gustó ver que, al menos en esta conferencia, la gente que usaba la nube tenía claro las ventajas y desventajas que tenía y que no era un dogma de fe.</li><li><b>"La “mal” entendida calidad en el desarrollo de software"</b>. Si algo me quedó claro en esta discusión es que todo en el desarrollo del software es contextual, incluida la calidad. Por supuesto, se habló de ser consciente de las decisiones que tomamos y de que la velocidad implica una dirección. Yo introduje el tema de la inercia y la madurez de los equipos, puesto que es fácil hablar de tener distintos niveles de calidad dependiendo del contexto, pero eso implica que el equipo es capaz de trabajar bien y seguro con distintas prácticas y que tendremos que absorber el coste basal del software desarrollado durante los distintos periodos y contextos (inercia).</li><li><b>"Productividad, métricas y ktlo"</b>. Otra gran discusión sobre cómo obtener el balance entre el medio plazo, la evolución de la arquitectura y la necesidad (más en una startup) de desarrollar features. Se vieron técnicas para visibilizar la importancia de la inversión en mejoras de arquitectura de plataforma, cómo priorizar cambios profundos identificados en postmortems y cómo medir el impacto de las mejoras que no estén directamente relacionadas con la entrega de features.</li></ul><p></p><p><br /></p>
<p>Me es muy difícil transmitir la calidad de las conversaciones y el nivel de las mismas. Lo importante del <a href="https://sosz.cachirulovalley.com/">SOSZ</a>, además de la organización impecable, es la gente que asiste, y el ambiente de compartir y aportar que se genera. Todas estas discusiones sobre la calidad, bajarse del cloud, o las métricas de productividad, son geniales porque se generan desde la experiencia y el conocimiento de gente muy crack, y es algo que en una conferencia al uso es muy difícil que suceda, puesto que no se da el contexto adecuado para que se genere esa conversación, y casi toda la comunicación es unidireccional (ponente-audiencia). De verdad, si no has asistido a un <a href="https://en.wikipedia.org/wiki/Open_space_technology">Open Space</a>, hazlo, y si puedes, hazlo en el <a href="https://sosz.cachirulovalley.com/">SOSZ</a>. Ya me lo agradecerás...</p>
<blockquote class="twitter-tweet"><p dir="ltr" lang="es">Desde el equipo del <a href="https://twitter.com/hashtag/SOSZ24?src=hash&ref_src=twsrc%5Etfw">#SOSZ24</a> os agradecemos el día de ayer y empezamos a trabajar ya en el <a href="https://twitter.com/hashtag/SOSZ25?src=hash&ref_src=twsrc%5Etfw">#SOSZ25</a> . ¡Muchas gracias a todas y todos por venir! <a href="https://t.co/0fAF1inOlm">pic.twitter.com/0fAF1inOlm</a></p>— Cachirulo Valley (@cachiruloValley) <a href="https://twitter.com/cachiruloValley/status/1766753832728473847?ref_src=twsrc%5Etfw">March 10, 2024</a></blockquote> <script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>
<p><br /></p><p><b>Muchísimas gracias a la <a href="https://www.cachirulovalley.com/">organización</a>, lo que hacéis es impresionante y lo que aprendo cada año es impagable.</b><br /><br />Referencias:</p><p></p><ul style="text-align: left;"><li><a href="https://sosz.cachirulovalley.com/">https://sosz.cachirulovalley.com/</a></li><li><a href="https://en.wikipedia.org/wiki/Open_space_technology">https://en.wikipedia.org/wiki/Open_space_technology</a></li></ul><p></p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-88179532771962395712024-03-03T12:12:00.003+01:002024-03-03T12:14:35.587+01:00CPS Live 2024 / Presentaciones<p>Ayer tuve el placer de asistir al evento CPS Live, un encuentro organizado por la incipiente comunidad CPS Hispana. La filosofía detrás de este evento era fomentar el intercambio de experiencias y aprendizajes, en un formato <a href="https://en.wikipedia.org/wiki/Open_Space_Technology">Open Space</a>, aunque con la particularidad de que las charlas fueron seleccionadas y votadas con antelación. Esto, supongo, con el objetivo de facilitar la organización y aprovechar al máximo el tiempo disponible, ya que el evento solo duró un día, de 9 a 16:30.</p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMYJC6zSz11i3CJ4FjoCdqAE6Njk-pQCynb7KMy77qVLJ1TD4Wen4WdoyNO7T_3XqP8PaI1GSRR-hwjkiwtEXF4_n5DFTRfLNYH6Xc9AZbnL0pucYp0UB6_444rTqgjV9Svp2lDs7eaNvgha9rH1KGLAGCOVpUVr_NqKKlMl7wVSRgPxcuYKQ6/s4080/cpslive_2024-1.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3072" data-original-width="4080" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMYJC6zSz11i3CJ4FjoCdqAE6Njk-pQCynb7KMy77qVLJ1TD4Wen4WdoyNO7T_3XqP8PaI1GSRR-hwjkiwtEXF4_n5DFTRfLNYH6Xc9AZbnL0pucYp0UB6_444rTqgjV9Svp2lDs7eaNvgha9rH1KGLAGCOVpUVr_NqKKlMl7wVSRgPxcuYKQ6/s320/cpslive_2024-1.jpg" width="320" /></a></div><br /><p><br /></p><p>Decidí presentar dos charlas que ya había ofrecido anteriormente, pensando que solo una sería seleccionada. Para mi sorpresa, ambas fueron elegidas, lo que me impidió asistir a otras ponencias y generó un notable FOMO (Fear Of Missing Out). Pero, al fin y al cabo, en un Open Space ocurre lo que tiene que ocurrir, así que no hay problema.</p><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvP_iefPOPhqBC5oO16OTed4Y4DNYIxkbzvK8vyststM99omIdmBWCbPjQbZyW41droiT4rLujHoramVBXOsJzKi9Cs61YuerOOwcHlTvJvP2j21htDxbvgbuK2m6wfynClMHPSwQ5Kmf4cpd2dgM5Zon7q2Gp-n15i7l1WIDoYfr_T4eWMS4e/s4080/cpslive_2024-3.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="4080" data-original-width="3072" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvP_iefPOPhqBC5oO16OTed4Y4DNYIxkbzvK8vyststM99omIdmBWCbPjQbZyW41droiT4rLujHoramVBXOsJzKi9Cs61YuerOOwcHlTvJvP2j21htDxbvgbuK2m6wfynClMHPSwQ5Kmf4cpd2dgM5Zon7q2Gp-n15i7l1WIDoYfr_T4eWMS4e/s320/cpslive_2024-3.jpg" width="241" /></a></div><p><br />Dejo aqui las presentacion que use en mis dos charlas.</p><h3 style="text-align: left;">Lean Coffee: Mental Models for Product Developers</h3><p>Utilicé el formato <a href="https://www.linkedin.com/pulse/what-heck-lean-coffee-florence-lowe/">Lean Coffee</a> para decidir cuánto tiempo dedicábamos a cada uno de los modelos mentales. Esto nos permitió cubrir temas como el Valor, la Eficiencia de Recursos vs. la Eficiencia de Flujo, el Costo Basal del Software, el Costo de Demora, los Perfiles de Urgencia, lo Crítico vs. la Incertidumbre, entre otros. En las diapositivas podéis encontrar el resto de temas que podríamos haber tratado.</p><p>Quería testear este formato en una conferencia y funcionó muy bien en mi opinión. No utilice el formato completo, sino que traje yo los temas a presentar, chequee con la audiencia si el orden que yo había preparado tenía sentido o quieren empezar con otro punto y lo que sí que hice es gestionar el tiempo para decidir cuantas rondas dedicamos a cada tema. Este formato fomenta la discusión y el feedback en cada punto y además permite un mejor control del tiempo al decidir colectivamente en qué enfocarse y durante cuánto tiempo.</p>
<h4 style="text-align: left;">Slides de la Charla</h4><iframe allowfullscreen="true" frameborder="0" height="569" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/e/2PACX-1vTVlFEs-2cr-uCNYYBqnKieCwKK5hSri-1S_9gsgrkLYYaiinDRcBiY_JaaMDnZBBOjMCOPHJtxfcu5/embed?start=false&loop=false&delayms=3000" webkitallowfullscreen="true" width="100%"></iframe><p><a href="https://docs.google.com/presentation/d/1VUUJ-dyBZbVYgy8m9ynTRQlHTA3dliWyXFmmTQ41qlI/edit?usp=sharing">Doc original</a> </p><p><br /></p><h3 style="text-align: left;">The Complexity Trap: Reevaluating Our Incentives</h3><p>Esta charla la preparé originalmente para DevOps Days Madrid, pero me pareció que encajaba perfectamente con el contenido del CPS Live, así que decidí repetirla con algunas adaptaciones. Lo más destacado fue la sesión de preguntas y discusiones que tuvimos después, que duró unos 20 minutos y resultó ser increíblemente enriquecedora.</p><p><br /></p>
<h4 style="text-align: left;">Slides de la Charla</h4><iframe allowfullscreen="true" frameborder="0" height="569" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/e/2PACX-1vShoh8R327DyRccGIRvauHMwlUhwnerHD9qygDhPVKzsE2vyZqDwWHTyPK0HqNB9ICOCMWabq_r9VGK/embed?start=false&loop=false&delayms=3000" webkitallowfullscreen="true" width="100%"></iframe><p><a href="https://docs.google.com/presentation/d/1oo7VRNGaYzUEMnKBFP8mlR7ItyvyysfU6olUKV_1Xno/edit?usp=sharing">Doc original</a> </p><p>Además, aquí les dejo un video de la charla en DevOps Days Madrid para quien tenga curiosidad:</p><p><a href="https://www.eferro.net/2023/10/devopsdays-madrid-complexity-trap.html">DevOpsDays Madrid: The Complexity Trap Reevaluating our incentives
</a></p><p><br /></p><h3 style="text-align: left;">Reflexiones sobre el Evento</h3><p>Me gustó mucho el evento. Me llevo muchas ideas para profundizar y siento la misma emoción que al inicio de otras comunidades de práctica. Espero que evitemos repetir los errores de comunidades como la agile o la DevOps, o al menos, que cometamos errores nuevos.</p><p>El networking durante el evento y en las cañas posteriores fue fantástico. Disfruté especialmente de las conversaciones con <a href="https://twitter.com/aquiestaThai">Sara</a> y <a href="https://twitter.com/anabuigues">Ana</a> de <a href="https://www.surfeandoelcambio.com/">Surfeando el Cambio</a>, con <a href="https://twitter.com/pedropaparicio">Pedro Pablo</a>, <a href="https://twitter.com/mdiezb">Miguel Ángel</a>, y me encantó discutir con <a href="https://twitter.com/ddamasd">Diana Damas</a> sobre las similitudes entre el desarrollo de producto ágil (el de verdad, no la versión descafeinada) y la gestión del cambio en proyectos CPS. Aunque me dejó mucha gente por mencionar, estas interacciones fueron un punto alto del evento para mí. Al mismo tiempo y despues de un acto social tan intentos, llegue a casa reventado y esta noche he dormido diez horas del tirón :)</p><p><br /></p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-39562593476514211382024-02-17T23:48:00.005+01:002024-02-17T23:48:44.027+01:00Bilbostack 2024: Mi crónica de la conferenciaEl pasado 27 de enero tuve la suerte de poder asistir a la duodécima edición de Bilbostack (<a href="https://bilbostack.com/">https://bilbostack.com/</a>), un evento que se celebra en Bilbao y que reúne a profesionales del mundo de la tecnología y el diseño.<div>Es una de mis conferencias favoritas y de la que he disfrutado en bastantes ediciones, tanto como asistente como ponente (<a href="https://www.eferro.net/2019/01/bilbostack-2019devops-is-not-what-you.html">https://www.eferro.net/2019/01/bilbostack-2019devops-is-not-what-you.html</a> y <a href="https://www.eferro.net/2022/01/talk-developer-experience-modern.html">https://www.eferro.net/2022/01/talk-developer-experience-modern.html</a>). Un año más, terminé encantado con la conferencia y con ganas de volver el próximo año. Dejo por aquí una crónica de la conferencia por si a alguien le ayuda a decidirse a asistir el próximo año. :) </div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiy2YfhZiJXgF1qOVUnJ21M8KyyHVxPSgECHUNGairfzjMUAUITjOVOKkqNHvIpn1jAMcUvQfsA9gd6ZZqcjJ5Idi_J4vyCTGCOu9ucEwV3KZM82EXRO6Db0grvW2TrV6IdOY6bgZSl90PdlI5Vp-E2lmcpwH6fgeGc3geeVEFVLdhvhrqMk2TS/s4080/2024-01-27%2009.02.54.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3072" data-original-width="4080" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiy2YfhZiJXgF1qOVUnJ21M8KyyHVxPSgECHUNGairfzjMUAUITjOVOKkqNHvIpn1jAMcUvQfsA9gd6ZZqcjJ5Idi_J4vyCTGCOu9ucEwV3KZM82EXRO6Db0grvW2TrV6IdOY6bgZSl90PdlI5Vp-E2lmcpwH6fgeGc3geeVEFVLdhvhrqMk2TS/s320/2024-01-27%2009.02.54.jpg" width="320" /></a></div><br /><div><br /></div><div><br /></div><div>Aparte de volver a mi tierra e ir a visitar a la familia, el evento me sirvió para ver a viejos amigos y hacer nuevos. Además, tuve la suerte de poder asistir a charlas muy interesantes. </div><div>La Bilbostack es una conferencia que "solo" tiene 8 charlas, organizadas en dos tracks paralelos. Las charlas son siempre de gran calidad y el ambiente es inmejorable.</div><div><br /></div><h2 style="text-align: left;">Charlas</h2><div>La primera charla a la que asistí fue la de Adrià Fontcuberta (<a href="https://twitter.com/afontq">https://twitter.com/afontq</a>), <b>"El arte de desarrollar: ¿En qué pensamos cuando pensamos en software?"</b>. Adrià nos habló de los modelos mentales que utilizamos para desarrollar software y de cómo estos afectan a la calidad del software que desarrollamos. Me encantó, y me sentí como si todo lo que comentaba Adrià fueran mis propias conclusiones. Explicó mediante metáforas y con ejemplos claros la importancia de los <b>feedback loops</b>, la simplicidad, la necesidad de ser capaces de posponer las decisiones mientras aprendemos lo más rápido posible para ir disipando la incertidumbre.</div><div>Espero que Adrià grabe la charla en algún momento para poder recomendarla a todo el mundo. De momento, os dejo el enlace a sus slides: <a href="https://noti.st/afontcu/kmdzCv/el-arte-de-desarrollar-en-que-pensamos-cuando-pensamos-en-software">https://noti.st/afontcu/kmdzCv/el-arte-de-desarrollar-en-que-pensamos-cuando-pensamos-en-software</a> y al blog post que Adrià escribió sobre la charla: <a href="https://afontcu.dev/bilbostack-2024/">https://afontcu.dev/bilbostack-2024/</a> </div><div><br /></div><div>Después de esta primera charla, intenté asistir a una relacionada con seguridad, pero había tantos amigos y conocidos, que para cuando llegué a la puerta de la sala, ya estaba llena :) En cualquier caso, no me arrepiento, puesto que una de las mejores cosas de la Bilbostack es el <b>networking</b>, así que aproveché para estar poniéndome al día con amigos y conocidos.</div><div><br /></div><div>La siguiente charla a la que asistí fue la de Mario López Martínez (<a href="https://www.linkedin.com/in/mariolopezmartinez/">https://www.linkedin.com/in/mariolopezmartinez/</a>), <b>"Ser data-driven no es de guapas"</b>. Mario nos habló de la dificultad de ser "data-driven" en una empresa, y de cómo la cultura de la empresa y la naturaleza humana dificultan la tarea. Me pareció una charla muy interesante y que me hizo reflexionar sobre la forma de trabajar en data engineering. Mario es un gran comunicador y, además de disfrutar del contenido de la charla, me estuve riendo un buen rato. Os dejo por aquí el enlace al post que Mario escribió sobre la charla: <a href="https://brain.drmario.tech/pages/%E2%9C%8D%EF%B8%8F+Ser+data-driven+no+es+de+guapas">https://brain.drmario.tech/pages/%E2%9C%8D%EF%B8%8F+Ser+data-driven+no+es+de+guapas</a></div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0_9nosiXulx4-0kDws64dDsWu0oxv8yH_SX9l1zhluZBtTU8V_CltJvoawdeBNn-Jqf5AgdDSy72OFPYN3-U63ykcolFt6pQLElqvbj8_EazlMoghjFiVigZzpvgsurG8JV1mUT1WWEGqh7G311Sht_1nl-jHyQBggs2eScA79ewOjpZwjL_w/s4080/2024-01-27%2013.12.52.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3072" data-original-width="4080" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0_9nosiXulx4-0kDws64dDsWu0oxv8yH_SX9l1zhluZBtTU8V_CltJvoawdeBNn-Jqf5AgdDSy72OFPYN3-U63ykcolFt6pQLElqvbj8_EazlMoghjFiVigZzpvgsurG8JV1mUT1WWEGqh7G311Sht_1nl-jHyQBggs2eScA79ewOjpZwjL_w/s320/2024-01-27%2013.12.52.jpg" width="320" /></a></div><br /><div><br /></div><div><br /></div><div>Por último, asistí a la charla de mi gran amigo Isidro López (<a href="https://twitter.com/islomar">https://twitter.com/islomar</a>), <b>"Valor por encima de código: el poder del Despliegue Continuo"</b>. Isidro nos habló de la entrega continua, de su importancia y de cómo llevarla a la práctica. Es un tema que me apasiona, y en esta ocasión lo disfruté doblemente puesto que hasta hace poco (y por segunda vez) Isidro y yo trabajamos juntos usando entrega continua. Por tanto, parte de los ejemplos usados eran de cómo trabajamos en algunos equipos de <a href="https://twitter.com/clarityaieng">ClarityAI</a>. La charla estuvo genial, y contenía mucha sabiduría y
experiencia. Me parece fundamental que se hable de esta forma de trabajar (<b>entrega continua, Trunk Based Development, XP</b>, etc.) puesto que para mucha gente parece algo lejano y casi utópico, pero la realidad es que llevo trabajando de esa forma desde hace al menos 14 años y no lo cambiaría por nada. Desarrollar software no tiene por qué ser un infierno lleno de ansiedad y estrés; puede ser un ritmo sostenible en el que disfrutes con tu trabajo mientras entregas valor a tus clientes de forma continua. Isidro ha publicado las slides y recursos de la charla en su blog: <a href="https://islomar.es/blog/talks/slides-and-resources-talk-bilbostack-2024/">https://islomar.es/blog/talks/slides-and-resources-talk-bilbostack-2024/</a> y además ha tenido la paciencia de contestar con detalle todas las preguntas que los asistentes le hicieron en la charla: <a href="https://islomar.es/blog/talks/preguntas-y-respuestas-bilbostack-2024/">https://islomar.es/blog/talks/preguntas-y-respuestas-bilbostack-2024/</a> </div><div><br /></div><div>Con mucha, lo más duro de la Bilbostack es la necesidad de elegir entre las charlas, puesto que al mismo tiempo de la charla de Isidro, me quedé con muchísimas ganas de asistir a la charla de Ujue Agudo (<a href="https://twitter.com/ujue">https://twitter.com/ujue</a>) y Karlos G (<a href="https://twitter.com/patxangas">https://twitter.com/patxangas</a>), <b>"Cuando las decisiones humanas se cruzan con los sistemas automatizados"</b>. Pero bueno, la vida es elegir.</div><div><br /></div><h2 style="text-align: left;">Networking</h2><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSPXDkotNfg3BT0AiMDn3quvnRQPghQWJgiUviiOyZp2VsDKc6rSKGDG0UUzX1i_hN0z7pmDnvcrCaYK7PzMGAvQvp0tiwD_3e9wVH3pdMHcTZemaoVtF-HHWq2l9L8Zy30sEdWASY4QA-n5yrlpV6inzuc4xIZ8TPTAKhud9dxOXktsE6ZsCS/s4080/2024-01-27%2015.14.48.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3072" data-original-width="4080" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSPXDkotNfg3BT0AiMDn3quvnRQPghQWJgiUviiOyZp2VsDKc6rSKGDG0UUzX1i_hN0z7pmDnvcrCaYK7PzMGAvQvp0tiwD_3e9wVH3pdMHcTZemaoVtF-HHWq2l9L8Zy30sEdWASY4QA-n5yrlpV6inzuc4xIZ8TPTAKhud9dxOXktsE6ZsCS/s320/2024-01-27%2015.14.48.jpg" width="320" /></a></div><br /><div><br /></div><div>Después de las charlas, llegó una de las <b>estrellas de esta conferencia, el networking</b>. En este año (creo que ya es el segundo), los organizadores de la Bilbostack han habilitado una zona en la explanada del museo marítimo de Bilbao para poder charlar con los asistentes, tomar algo y disfrutar del buen ambiente. Me encanta esta parte de la conferencia, puesto que es una oportunidad para charlar con amigos, conocidos y desconocidos. Creo que el lugar es una gran elección puesto que está muy cerca del Palacio Euskalduna, donde se celebra la conferencia, y además es un lugar espacioso.</div><div>Hace algunos años, el networking era en la <a href="https://turismo.euskadi.eus/es/plaza-nueva-bilbao/aa30-12375/es/">Plaza Nueva</a>, y aunque era un lugar mucho más típico, estaba más lejos de donde se hace la conferencia y, al ser un sitio público, los organizadores no podían fácilmente controlar el aforo u organizar actividades. </div><div>Con la decisión de hacerlo en la explanada del museo, les ha permitido poner puestos de comida y bebida, hacer actividades y tener más flexibilidad sobre la experiencia de los asistentes. Ni que decir tiene que disfruté como un puerco en la charca, charlando con amigos, conocidos y desconocidos.</div><div>Me hubiera encantado seguir el networking hasta altas horas de la madrugada, pero al ser de Bilbao tenía otros compromisos, así que me tuve que ir pronto.</div><div>En cualquier caso, un acierto el nuevo formato de networking. </div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjA-o7KwnLSiTblRxtC45PTXki9ItWVMtSRsD6J4gqltuoFLpu9mp1NYckEXrxi46Mg8UkBvA4m9fGuZs0d8-bI0FK5eRDJ1Aq8bQpgTrr5sy5uOxCh68p8kCiKCXBMQ6e6F8XplpSPwBlRdIVqK0kvvNIr0CjPt2jORetO-FYgG12singV68Cb/s4080/2024-01-27%2016.07.20.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3072" data-original-width="4080" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjA-o7KwnLSiTblRxtC45PTXki9ItWVMtSRsD6J4gqltuoFLpu9mp1NYckEXrxi46Mg8UkBvA4m9fGuZs0d8-bI0FK5eRDJ1Aq8bQpgTrr5sy5uOxCh68p8kCiKCXBMQ6e6F8XplpSPwBlRdIVqK0kvvNIr0CjPt2jORetO-FYgG12singV68Cb/s320/2024-01-27%2016.07.20.jpg" width="320" /></a></div><br /><div><br /></div><div><br /></div><div> En resumen, la Bilbostack 2024 fue<b> una conferencia genial, con charlas de gran calidad y un ambiente inmejorable</b>. Me encanta que se celebre en Bilbao, y que sea una conferencia pequeña y acogedora. Espero poder asistir el próximo año y volver a disfrutar de la comunidad.<br /><br /></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-82990400638972238082024-01-31T19:44:00.001+01:002024-01-31T19:47:35.750+01:00Selección de charlas recomendadas en español<p> </p>
Normalmente comparto en este blog el contenido (charlas/podcast) que encuentro interesantes. La mayoría del contenido es en inglés, pero con el paso del tiempo he ido acumulando algunas que son en castellano y merecen mucho la pena. Espero que las disfruteís...
<ul>
<li>
<a href="https://www.youtube.com/watch?v=g-WGDoItqiA">Aquí también hay esperanza</a>
<b>(Modesto San Juan)</b>
<b>[Engineering Career, Inspirational]</b>
<b>[Duration: 01:22]</b>
Inspiradora charla sobre nuestra profesión de eternos aprendices. Imprescindible.
</li>
<li>
<a href="https://www.youtube.com/watch?v=y3MWfPDmVqo">Clean Architecture: La mejor forma de escalar y mantener tu código</a>
<b>(Rafa Gómez)</b>
<b>[Architecture, Design, hexagonal]</b>
<b>[Duration: 00:18]</b>
Muy buena descripción de las arquitecturas limpias y de la arquitectura hexagonal. Muy didactico.
</li>
<li>
<a href="https://www.youtube.com/watch?v=AIsMkTBNIeI">Artefactos en la gestión de Producto</a>
<b>(Vanesa Tejada)</b>
<b>[Product]</b>
<b>[Duration: 01:06]</b>
Interesante charla en la que Vanesa nos comparte los artefactos que usa para mejorar el proceso de producto a escala (radiadores de información, tracking, etc).
</li>
<li>
<a href="https://www.runroom.com/realworld/e019-que-es-y-para-que-sirve-la-cultura-organizacional">E019 Qué es y para qué sirve la cultura organizacional</a>
<b>(Xavi Gost, Carlos Iglesias)</b>
<b>[Agile, Company Culture, Culture]</b>
<b>[Duration: 00:59]</b>
Realworld podcast Ep 19.
</li>
<li>
<a href="https://www.youtube.com/watch?v=AWBh_ftm-iI">Startup School: Restart "Motivación y responsabilidad"</a>
<b>(Félix López)</b>
<b>[Engineering Career, Inspirational, Product]</b>
<b>[Duration: 00:56]</b>
"ownership" o responsabilidad, una de las grandes tendencias en muchos artículos sobre productividad y efectividad para gestionar equipos y que pocas veces se explica en profundidad cómo conseguirla o las principales razones para hacerlo.
</li>
<li>
<a href="https://www.youtube.com/watch?v=IqUo9kCWQrw">Aprender a distinguir el problema de las soluciones</a>
<b>(Carlos Ble)</b>
<b>[Agile, Engineering Culture, Product, Lean Software Development]</b>
<b>[Duration: 00:41]</b>
<b>(⭐⭐⭐⭐⭐)</b>
En esta sesión Carlos se centra en cómo saber separar el "Qué" del "Cómo" para ser eficaces y económicos resolviendo problemas, sin que la calidad de las soluciones se vea afectada. Una muy buena charla para cualquiera que se interese por el desarrollo de software lean (agile real).
</li>
<li>
<a href="https://www.youtube.com/watch?v=pp8j1ggCaoM">CDD (Desarrollo dirigido por consenso)</a>
<b>(Xavi Gost)</b>
<b>[Agile, Engineering Culture, Lean Software Development]</b>
<b>[Duration: 00:58]</b>
<b>(⭐⭐⭐⭐⭐)</b>
En esta charla, Xavi introduce el concepto de 'Desarrollo Dirigido por Consenso' junto con el 'Sistema de Concerns'. Esta metodología resulta ser una práctica sumamente efectiva para optimizar el flujo de trabajo en equipos, manteniendo al mismo tiempo bajo control la deuda técnica y abordando eficientemente los menores problemas de diseño identificados por el equipo. Tras observar la implementación de esta metodología en varios equipos, puedo afirmar que su utilidad es significativa.
</li>
<li>
<a href="https://www.youtube.com/watch?v=mqjvkL2h3_I">La economía del refactoring. Una visión desde la gestión económica del proyecto.</a>
<b>(Xavi Gost)</b>
<b>[Inspirational, Technical Practices, XP]</b>
<b>[Duration: 00:51]</b>
Inspiracional charla sobre las motivaciones y la estrategia para refactorizar de forma continua.
</li>
<li>
<a href="https://www.youtube.com/watch?v=n-l4vSVJkNY">¿Que es un programador y cual es su papel en la sociedad?</a>
<b>(Xavi Gost)</b>
<b>[Inspirational, ethics, professionalism]</b>
<b>[Duration: 00:34]</b>
Buena reflexión sobre el papel del desarrollador en la sociedad y la necesidad de una etica profesional fuerte.
</li>
<li>
<a href="https://www.youtube.com/watch?v=ikTqt0Vot_s">Unexpected inhabitants: algorithms, ethics, and emergency</a>
<b>(Aitor García Rey)</b>
<b>[Inspirational, ethics, professionalism]</b>
<b>[Duration: 00:21]</b>
Interesante charla para comprender el contexto del cambio que estamos experimentando debido a la entrada masiva de software (y ahora de la Inteligencia Artificial) en todos los aspectos de nuestra sociedad. Invita a la reflexión.
</li>
<li>
<a href="https://www.youtube.com/watch?v=i8GzkkMWGYE">Case Study: tools and strategies for tackling legacy practices</a>
<b>(Alejandro Scandroli)</b>
<b>[Engineering Culture, Technical leadership]</b>
<b>[Duration: 00:48]</b>
Ejemplo práctico del uso de los Wardley Maps y algunos conceptos de DDD (strategic design) para proponer una estrategia para el equipo de Ingenieria.
</li>
<li>
<a href="https://www.youtube.com/watch?v=MtwyXiuW1OU">Connectsai 2020: Cómo entregar más por menos - Marta Manso</a>
<b>(Marta Manso)</b>
<b>[Lean Product Management, Product, Product Discovery, Product Engineer]</b>
<b>[Duration: 00:57]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Inspiradora charla de Marta sobre como trabajar en un equipo enfocado a dessarrollo de producto y que entiende la tecnologia como un medio. Gran cantidad de ideas y detalles interesantes.
</li>
<li>
<a href="https://youtu.be/N6OJg1rxZGE">Muda, Mura, Muri: mitos y prácticas aplicando Lean Software Development</a>
<b>(Abraham Vallez)</b>
<b>[Agile, Lean Software Development, XP]</b>
<b>[Duration: 00:55]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Excelente charla que se fundamenta en experiencias prácticas acerca de cómo colaborar eficazmente en equipo, siguiendo los principios del desarrollo de software Lean y de Programación Extrema (XP). Constituye un recurso valioso para recomendar o compartir con equipos que buscan optimizar sus metodologías de trabajo.
</li>
<li>
<a href="https://www.youtube.com/watch?v=JzWZkqem5-8">Product minded software crafter</a>
<b>(Cansu Karayel, Gemma Cortel)</b>
<b>[Lean Product Management, Lean Software Development, Small Safe Steps (3s)]</b>
<b>[Duration: 00:38]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Ejemplo real de como un equipo de desarrollo de producto en el que todo el mundo entiende el software como un medio puede tener un gran impacto.
</li>
<li>
<a href="https://www.youtube.com/watch?v=wTkiIF6UhKQ">Tips & tricks para llegar a ser un equipo de alto rendimiento</a>
<b>(Iván Badia)</b>
<b>[Agile, Engineering Culture, Lean Software Development]</b>
<b>[Duration: 00:53]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Iván da las claves para tener una cultura de ingenieria sana en el que los equipos tienen una aproximación lean y con buenas prácticas para el desarrollo de producto. Muy alineado con las ideas descritas en la charlas.
</li>
</ul>
<br />
<b>Relacionado:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-5331834321129765702024-01-22T13:25:00.001+01:002024-01-22T13:25:58.795+01:00Good talks/podcasts (Jan 2024 II)<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwecTEYzwF3qN-fxaVO0KxpFu5GMR8pj54Cl8MJQ1HiLyPhLwfyBko2OP4Vo9U6N0fli8U3FHJiEZ7sm5sowVYN1rLOC9dawUF6GU9YY6YMiyM3xXtTJyjA1plN4x-7BFdLQ5LA4S-48-aBvH6XDa88fX6EAQlytV6iDml3vUjqsFpqmCBJWpb/s1024/DALL%C2%B7E%20ensemble.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="320" data-original-height="1024" data-original-width="1024" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwecTEYzwF3qN-fxaVO0KxpFu5GMR8pj54Cl8MJQ1HiLyPhLwfyBko2OP4Vo9U6N0fli8U3FHJiEZ7sm5sowVYN1rLOC9dawUF6GU9YY6YMiyM3xXtTJyjA1plN4x-7BFdLQ5LA4S-48-aBvH6XDa88fX6EAQlytV6iDml3vUjqsFpqmCBJWpb/s320/DALL%C2%B7E%20ensemble.png"/></a></div>
<p> </p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=mVY2rFninp8">Rockstar Developers Are THE WORST Developers</a>
<b>(Dave Farley)</b>
<b>[Engineering Career, Engineering Culture]</b>
<b>[Duration: 00:17]</b>
Dave explains clearly why what the industry often calls a RockStar developer is by no means a good developer, and why we should change that definition to focus on teams and disciplined developers who work in teams rather than individually. My notes on the topic: https://www.eferro.net/2024/01/be-humble-no-rockstars-allowed.html
</li>
<li>
<a href="https://www.youtube.com/watch?v=YtROlyWWhV0">Polly Want a Message</a>
<b>(Sandi Metz)</b>
<b>[OOP]</b>
<b>[Duration: 00:41]</b>
A good talk by Sandi about how to create and evolve applications with good OO design. Like all of Sandi's talks, it is very worthwhile.
</li>
<li>
<a href="https://www.youtube.com/watch?v=yBEcq23OgB4">DDD Europe 2023. A Daily Practice of Empirical Software Design</a>
<b>(Kent Beck)</b>
<b>[Small Safe Steps (3s), Software Design, XP]</b>
<b>[Duration: 00:59]</b>
Interesting reflection on the economics of software design and the principles that affect it. This talk describes some of the ideas that Kent elaborates on in detail in his new book 'Tidy first?'
</li>
<li>
<a href="https://www.youtube.com/watch?v=NDXV16uheNs">GeePaw Hill on Incremental Software Delivery</a>
<b>(GeePaw Hill)</b>
<b>[Small Safe Steps (3s), Software Design, XP]</b>
<b>[Duration: 01:18]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Pure wisdom on why working in small, safe steps is the most efficient way to work in software product development when we have environments of high uncertainty (which is almost always).
</li>
<li>
<a href="https://www.youtube.com/watch?v=ikrNZxKOrJQ">“Industry Changing Book” | Jez Humble & Dave Reflect On Continuous Delivery</a>
<b>(Jez Humble, Dave Farley)</b>
<b>[Continuous Delivery]</b>
<b>[Duration: 01:06]</b>
This is an interesting talk by the two authors of the book 'Continuous Delivery' about the impact the book has had on the industry.
</li>
</ul>
<b>Reminder:</b> All of these talks are interesting, even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-44376446971109928912024-01-21T15:24:00.001+01:002024-01-21T15:24:12.063+01:00Best talks that I recommended in 2023<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhsoBW-Lhicq2Lgz-abBWvoHK7LMVpGcPVJB08A6I2ZgNzf2C87DbEjtI5Z67XziHiXq9hxhgNMTaXBNs1Sf899eax7TzMbdnwkvDjecE1-wNKKG-nyq_bwDwqYO0n5_tHS1S2HEqHSo0_5nOF7WpMwlaiZEFwS0v1ZVsd8AufV_OD3aOnZbdw/s1024/best_talks_2023.jpeg" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="320" data-original-height="1024" data-original-width="1024" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhsoBW-Lhicq2Lgz-abBWvoHK7LMVpGcPVJB08A6I2ZgNzf2C87DbEjtI5Z67XziHiXq9hxhgNMTaXBNs1Sf899eax7TzMbdnwkvDjecE1-wNKKG-nyq_bwDwqYO0n5_tHS1S2HEqHSo0_5nOF7WpMwlaiZEFwS0v1ZVsd8AufV_OD3aOnZbdw/s320/best_talks_2023.jpeg"/></a></div>
<p> As some of you know, I maintain a database of the talks and podcasts that I watch or listen to. I usually save a description, the topics discussed, and a rating. I often use this database to make recommendations or to search for ideas and content.</p><p><br /></p>
<p>This is the list of all the talks or podcasts that I recommended during this past year (2023) and to which I assigned a rating of 5/5:</p>
<ul>
<li>
<a href="https://www.youtube.com/watch?v=F87PtAoJNtg">"Simple Made Easy" (12-minute redux) by Rich Hickey (2011)</a>
<b>(Rich Hickey)</b>
<b>[Architecture, Inspirational, Scalability, Software Design]</b>
<b>[Duration: 0:12]</b>
This is a 12-minute redux of the 1-hour talk by Rich Hickey, for really impatient people. Original: <a href="https://www.youtube.com/watch?v=SxdOUGdseq4">https://www.youtube.com/watch?v=SxdOUGdseq4</a>
</li>
<li>
<a href="https://www.youtube.com/watch?v=qKLnlaWKkb4">Architecture for Flow with Wardley Mapping, DDD, and Team Topologies</a>
<b>(Susanne Kaiser)</b>
<b>[DDD, Engineering Culture, Technology Strategy, Wardley maps, team topologies]</b>
<b>[Duration: 0:43]</b>
This talk illustrates the concepts, connects the dots between DDD, Wardley mapping and team topologies, and demonstrates how these techniques help to evolve a fictitious legacy system for a fast flow of change.
</li>
<li>
<a href="https://www.youtube.com/watch?v=mcnxxdzC2fY">Master Class with Marty Cagan</a>
<b>(Marty Cagan)</b>
<b>[Inspirational, Product, Product Discovery, Product Leadership, Product Team, leadership]</b>
<b>[Duration: 1:21]</b>
A great presentation on skilled product teams and leading product organizations. The questions at the end are also very interesting.
</li>
<li>
<a href="https://www.youtube.com/watch?v=a_T21Lf26pc">Artificial Intelligence seen from the software development lifecycle perspective</a>
<b>(Nerea Luis)</b>
<b>[AI, MLOps]</b>
<b>[Duration: 0:54]</b>
Great introduction to the differences between traditional software development and the development cycle with AI models. Nerea introduces concepts such as Continuous training, model deployment, MLOps, and collaboration between data scientists and software engineers. Highly recommended for software engineers looking to delve into these topics and collaborate more closely on AI-based feature development.
</li>
<li>
<a href="https://www.youtube.com/watch?v=kKbQ2-dXsmE">CONSTANT Changes To User Requirements Drive Me CRAZY</a>
<b>(Dave Farley)</b>
<b>[Agile, Continuous Delivery, Inspirational, Lean Product Management, Lean Software Development]</b>
<b>[Duration: 0:13]</b>
This presentation by Dave Farley shows that software development is not just about translating perfect requirements into code, but rather a process of discovery and exploration. It acknowledges that the nature of the problems being solved has changed and that it is impossible to have all the answers. It emphasizes that successful software products must be able to adapt and evolve over time, and that the key to success is embracing change and making it easy, safe, and low-cost.
</li>
<li>
<a href="https://www.youtube.com/watch?v=xcQVgYzlj8k">Systems Thinking for Developers</a>
<b>(Jessica Kerr)</b>
<b>[Inspirational, Mental models]</b>
<b>[Duration: 0:55]</b>
Great explanation of how system thinking arises and its basic concepts. System thinking is a fundamental tool to work with/in complex systems such as software systems.
</li>
<li>
<a href="https://www.youtube.com/watch?v=kJdXjtSnZTI">Simon Sinek Performance vs Trust</a>
<b>(Simon Sinek)</b>
<b>[Company Culture, Culture, Inspirational]</b>
<b>[Duration: 0:02]</b>
Great description of the impact of trust on team members and leaders.
</li>
<li>
<a href="https://www.youtube.com/watch?v=XMyt5S8limQ">Improving Software Flow</a>
<b>(Randy Shoup)</b>
<b>[Devops, Flow, Inspirational, Lean, Lean Software Development, Technical leadership, leadership]</b>
<b>[Duration: 0:50]</b>
In this session, Randy explains how they improve the overall flow and the engineering capacity following the ideas in the Unicorn Project (Locality and Simplicity, Focus, Flow, and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus). It is an excellent talk about generating/improving an engineering culture following lean principles.
</li>
<li>
<a href="https://www.youtube.com/watch?v=lHoOUylvfxQ">Many More Much Smaller Steps with GeePaw Hill</a>
<b>(GeePaw Hill, Chris Lucian, Austin Chadwick)</b>
<b>[Evolutionary Design, Lean Software Development, Software Design, Technical Practices, XP]</b>
<b>[Duration: 0:39]</b>
Good conversation about GeePaw Hill's software development approach based on taking continuous small safe steps (Many More Much Smaller Steps).
</li>
<li>
<a href="https://www.youtube.com/watch?v=rP7bpYsfa6Q">Tips For Technical Startup Founders | Startup School</a>
<b>(Diana Hu)</b>
<b>[Inspirational, Lean Software Development, Lean Startup, startup]</b>
<b>[Duration: 0:28]</b>
Diana Hu shares her advice for being a technical founder at the earliest stages - including topics like how to ship an MVP fast, how to deal with technology choices and technical debt, and how and when to hire an engineering team.
</li>
<li>
<a href="https://www.youtube.com/watch?v=hIMwTzAAQ-w">Oredev 2011: Sleeping with the enemy</a>
<b>(Gojko Adzic)</b>
<b>[Engineering Culture, testing]</b>
<b>[Duration: 0:52]</b>
Gojko Adzic describes why independent testing should be a thing of the past. He explains how testers engaging with developers and business users create opportunities to accomplish things they cannot do otherwise.
</li>
</ul>
<p><br /></p><p>It should be noted that I recommended them last year, but that does not imply that the talk or podcast is from 2023, in fact I think most of them are much older.</p><p><br /></p><p>I hope you find these recommendations helpful.</p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-72562808799625175472024-01-14T22:09:00.001+01:002024-01-14T22:59:00.576+01:00Good talks/podcasts (Jan 2024 I)<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv8lRUVIbCtxTqpiY8IxI6B713ZT1fD3j_JBr8QQ7UUlDu8OVXwFQ94ncCN8AonHJ0oE6HVCZoPXi0jkdNCwl9IuFmwc1t-u5vA3zf0SlgwD4wTEUEPlLpHHiXCxAJHCJ_3h1CGNyqiQoCGQ9AX_MZZeEzWVTQIrgQZBUlWviMau6uA-Rnp8yo/s1024/DALL%C2%B7E%202024-01-14-Technical_talks_I_recommend.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" width="320" data-original-height="1024" data-original-width="1024" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv8lRUVIbCtxTqpiY8IxI6B713ZT1fD3j_JBr8QQ7UUlDu8OVXwFQ94ncCN8AonHJ0oE6HVCZoPXi0jkdNCwl9IuFmwc1t-u5vA3zf0SlgwD4wTEUEPlLpHHiXCxAJHCJ_3h1CGNyqiQoCGQ9AX_MZZeEzWVTQIrgQZBUlWviMau6uA-Rnp8yo/s320/DALL%C2%B7E%202024-01-14-Technical_talks_I_recommend.png"/></a></div>
<p> </p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=44sJLFgzhn4">Big Transitions in Small Steps</a>
<b>(Kent Beck)</b>
<b>[Agile, Software Design, Technical Practices]</b>
<b>[Duration: 0:59:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Very deep ideas about how to make any kind of huge technical change using small and incremental changes. This part of the core of agile... Vertical slicing to make changes in small (low risk) steps.
</li>
<li>
<a href="https://www.youtube.com/watch?v=2rUbNSDLfxY">Laloux Culture Model and Agile</a>
<b>(AgileForAll)</b>
<b>[Agile, Company Culture, Culture, Inspirational, Lean]</b>
<b>[Duration: 0:09:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
An overview of Frederic Laloux's Reinventing Organizations and how it relates to Lean and Agile Adoption.
</li>
<li>
<a href="https://www.youtube.com/watch?v=tuunGZ-4wPQ">Compliance standards should be modern development practices</a>
<b>(Charity Majors)</b>
<b>[Compliance, Engineering Culture, Security]</b>
<b>[Duration: 0:37:00]</b>
Great talk in which Charity explains how to maintain good engineering practices in regulated environments while meeting the corresponding compliance requirements. The talk doesn't have a high level of detail, but provides ideas for a general approach.
</li>
<li>
<a href="https://podcasts.apple.com/gb/podcast/scalex-insider-podcast/id1566729230?i=1000599670214">Paul Akers - How to apply lean thinking to your business for success</a>
<b>(Paul Akers)</b>
<b>[Lean, Lean Manufacturing]</b>
<b>[Duration: 0:57:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Very interesting conversation with Paul Akers who speaks from experience on how to apply lean thinking and continuous improvement.
</li>
<li>
<a href="https://www.youtube.com/watch?v=PSIPhVjWBO0">A Young Lady's Illustrated Primer to Technical Decision-Making</a>
<b>(Charity Majors)</b>
<b>[Engineering Culture, Technical leadership]</b>
<b>[Duration: 0:41:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Fun and interesting talk about the context and process for making technical decisions. Very good ideas. The talk is a few years old, but the ideas are still very valid. Charity talks about how to decide to introduce new technologies, the cost of maintaining them, the importance of migrations, failure modes, etc.
</li>
<li>
<a href="https://www.infoq.com/podcasts/dagger-devops-docker/">Solomon Hykes Discusses Dagger, DevOps, and Docker</a>
<b>(Solomon Hykes)</b>
<b>[Continuous Delivery, Developer Productivity, Devex, Operations]</b>
<b>[Duration: 0:43:00]</b>
Interesting podcast about the current problems of CI/CD pipelines and how they aim to solve them from Dagger. There are also interesting opinions from the perspective of creating technical products geared towards developers and about the development experience.
</li>
</ul>
<b>Reminder:</b> All of these talks are interesting, even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-38413834659727687912024-01-06T21:23:00.002+01:002024-01-14T19:44:24.991+01:00Be humble, no Rockstars allowed<p>Continuous delivery is based on the hypothesis that when facing uncertainty and complex problems (see <a href="https://www.mindtools.com/atddimk/the-cynefin-framework">Cynefin</a>), the appropriate strategy is to assume that we do not know the solution and must continuously learn about the problem and the best possible solution. Additionally, continuous delivery forces us to put in place means to manage errors, which we are sure to make with minimal impact.</p><p>If we assume that we know the solution or the problem is sufficiently simple (or just complicated in Cynefin terms), continuous delivery and learning are not the most efficient strategies. In these cases, a direct approach is better, made by some team that has already done it before. However, do not expect to learn anything or improve anything. On the other hand, if it has been done before, doing it again would simply be a waste that we should try to avoid.</p><p>"The only way it's all going to go according to plan is if you don't learn anything." - Kent Beck</p><h3 style="text-align: left;">My experience and context</h3><p>In my case:</p><p></p><ul style="text-align: left;"><li>I assume that what I come up with is not the best solution.</li><li>I assume that I have (we have many faults) in developing (I can't even do the 'hello world' right the first time).</li><li>I assume that we still have a lot to learn about everything (domain, business, tools, needs, etc).</li></ul><p></p><p>And I have never been in complicated or simple contexts where a better solution had already been made. And if I came across one, <b>I would try by all means not to build a new solution</b> (to avoid waste).</p><p>In this context, the discipline of lean product development, with continuous delivery (focused on continuous flow), continuous learning, and sustainable quality, is the best option I know.</p><p><br /></p><h3 style="text-align: left;">For Self-Sufficient Experts</h3><p>If you consider yourself an expert in everything, who rarely makes mistakes and feels like a 'rockstar' in their field, you might think that you don't need continuous delivery. I suspect that humility and recognizing that EVERYONE (including yourself) makes mistakes are lacking in this case. Maybe I am wrong, and you are some mythological being who does not make mistakes and does not need to learn continuously. If that is the case, my apologies… :)</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLsIx422gnBM6YDpsVSwv06kLkGQJJ7pyWLxIm1WX5Ip-BtzmMrDW6FhEs2KPd0x1n0MaohSUdySlOkJrS1mzZSZltKUN9qJzTPrtG3Uu1NSKRPdFl8UhQYRX92TC5VXsSh4vPSarrimuFElsI5v6UL8fY_SWdbpBpXNuBWZEWpdkQPSgrucah/s1024/DALL%C2%B7E_superhero_dev.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1024" data-original-width="1024" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLsIx422gnBM6YDpsVSwv06kLkGQJJ7pyWLxIm1WX5Ip-BtzmMrDW6FhEs2KPd0x1n0MaohSUdySlOkJrS1mzZSZltKUN9qJzTPrtG3Uu1NSKRPdFl8UhQYRX92TC5VXsSh4vPSarrimuFElsI5v6UL8fY_SWdbpBpXNuBWZEWpdkQPSgrucah/s320/DALL%C2%B7E_superhero_dev.png" width="320" /></a></div><p><br /></p><p><b>However, I won’t be able to work with you since I do make mistakes and need to be in a team that uses techniques that allow us to develop products despite errors without living in constant stress.</b></p><p><br /></p><h3 style="text-align: left;">In summary</h3><p>I believe that the general trick of this profession is to do teamwork in the best way we know how, with the best techniques we know, and still assume that we are going to make mistakes, that we have to keep learning, that we need to improve, and that we need a quality that allows us to be sustainable. The discipline of continuous delivery (CD, TBD, TDD, etc.) provides me with all of that...</p><p>Please...</p><p></p><ul style="text-align: left;"><li>Be a great team player. Collaborate and get involved.</li><li>Create a safe learning environment for your team.</li><li>Program as best you can but assume that you will fail, so create an environment where failing is manageable and has a low impact on customers.</li><li>Make the best architectural decisions you can, but assume that you will have to continuously improve it (evolve it).</li><li>Seek continuous delivery (as a goal that helps us generate the right discipline and a safe work environment).</li><li>Be humble and accept failure, uncertainty, and lack of knowledge.</li></ul><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZFqyuFcyO0ivuAO6n70i2-r3vjGPKxlae3t5tjh8376X479OpDM70b55aGfiML_FxATbY7OJq4cCpihBp2v4XW_mrdHMQQuq8VIhnxnVinPqZsVeGX11VGK6idaICvoOlCS1hS8P000Zh336G7LhCoSn_G8YnTlEJzeinZQq9m7FJbmVdNpmL/s1024/DALL%C2%B7E%20ensemble.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1024" data-original-width="1024" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZFqyuFcyO0ivuAO6n70i2-r3vjGPKxlae3t5tjh8376X479OpDM70b55aGfiML_FxATbY7OJq4cCpihBp2v4XW_mrdHMQQuq8VIhnxnVinPqZsVeGX11VGK6idaICvoOlCS1hS8P000Zh336G7LhCoSn_G8YnTlEJzeinZQq9m7FJbmVdNpmL/s320/DALL%C2%B7E%20ensemble.png" width="320" /></a></div><br /><p><br /></p><p>I don't want to work with RockStars, nor with x10 developers… I want to work in x10 teams and environments, where learning is constant, questioning is accepted, errors are accepted (since they are low cost) and improvement is continuous.</p><p>Remember:</p><p><b>We need professionals, not heroes.</b></p><p></p><blockquote>“I’m Not a Great Programmer, I’m Just a Good Programmer With Great Habits.” — Kent Beck</blockquote><p></p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-69767278493899752572023-12-31T12:59:00.002+01:002023-12-31T13:02:32.430+01:00Low friction cli tools using docker<p>Although I last wrote about technical topics here a while ago, I would like to share some ideas that are helping me reduce friction in creating tools for my colleagues at ClarityAI.<br />As the Platform Lead, among other things, I am involved in the development experience, which means that my team creates tooling (as part of our platform) for the rest of the engineering and data science teams in the company. This tooling includes command-line tools that help users use our platform with minimal friction and autonomously (without requiring support).<br />In our case, this means we want command-line tools with the following characteristics:</p><p></p><ul style="text-align: left;"><li>Usable on Linux and Mac</li><li>Low friction for usage (easy installation and usage)</li><li>Easy to evolve</li><li>Easy to distribute to all our users</li><li>Few external dependencies so that our users don't have to install additional tools</li></ul><p></p><p>In this context, and considering that we are already heavy users of Docker, it is a good idea to implement these types of tools as Docker images that our users can use.<br />This would allow us to include any external tools our users may need in the Docker images and eliminate friction by not requiring them to install those tools.</p><p>At the same time, using Docker presented its own challenges:</p><p></p><ul style="text-align: left;"><li>Difficulty in distributing a Docker image from a private repository</li><li>Difficulty in usage for execution requiring many parameters (volumes, environment variables, execution parameters and arguments, etc.)</li></ul><p></p><p>Below, I will explain how we have solved (or are in the process of solving) each of the mentioned challenges.</p><h3 style="text-align: left;">Controlled Environment</h3><div style="text-align: left;">Any modern development platform is implemented using different technologies and solutions.<br />This means the user must use different clients for each of these technologies (kubectl, AWS CLI, Git, Teleport, etc.).<br />To eliminate friction, avoid installation problems, and reduce the number of potential issues due to misuse or using incorrect versions, what has worked very well for us is to include all these tools (with controlled versions and environment) in a Docker image along with code to control their usage and configuration.<br />This allows the platform team to forget about problems caused by using the wrong version of kubectl or incorrect AWS client configuration.</div><h3 style="text-align: left;">Installation</h3><div style="text-align: left;">If the installation process of a tool is complicated, you can be sure that a significant percentage of users will encounter problems and require support.<br />It is often assumed that good documentation is sufficient, but no matter how good the documentation is, if there are many steps to follow and many tools to install, there will be problems.<br />A better solution is to create a specific installer without configuration and with the fewest possible dependencies.<br />In our case, the tool to be distributed was built with Docker and stored in a private repository (AWS ECR).<br />As a lean team, we have iteratively improved the solution, reducing friction at each step:</div><p></p><ol style="text-align: left;"><li>Installation instructions are documented in the engineering handbook. It depends on Docker, properly configured AWS CLI, and knowledge of ECR.</li><li>Installer script in the code repository. It improved the experience and generated a helper script for future usage. It depends on Docker and properly configured AWS CLI but does not require knowledge of ECR.</li><li>Cross-platform installer implemented with Golang. This is the version currently in development. It only requires Docker, and the user has an AWS Key. (Example: <a href="https://gist.github.com/eferro/cce7500cbe90a24eb77e59000a45babe">ECR Docker image puller / installer</a>)</li></ol><p></p><h3 style="text-align: left;">Execution</h3><div style="text-align: left;">When we create an open-source solution or a product that will be used in different environments, the ability to configure and adapt it to different environments is crucial.<br />But when we develop a tool for our colleagues and our goal is to minimize friction and reduce cognitive load, we need to provide the minimum necessary flexibility.<br />We can even avoid the need for any parameters. <br />This becomes a challenge when you have a tool built with Docker that requires multiple credentials and the ability to modify files on the user's machine, as it requires running Docker with many parameters and environment variables.<br />Once again, iteration has allowed us to improve the solution. The steps we have taken are:<br /><ol style="text-align: left;"><li>Document all the parameters and environment variables for tool execution in the README. This serves us well for development, but we never intended for our users to use the tool following this documentation.</li><li>Using an execution script that hides all the parameters and variables. In our case, this execution script was generated by the installer.</li><li>Cross-platform wrapper implemented in Golang. This allows us to distribute a binary that only depends on having Docker and hides the tool's complexity. This is the version we will distribute soon. (Example: <a href="https://gist.github.com/eferro/3b0f60d31df4c350774f99d54cd8f61e">Simple wrapper to execute (interactive/non interactive) docker image</a>)</li></ol></div><h3 style="text-align: left;">Continuous Updating</h3><div style="text-align: left;">In addition to facilitating installation, it is essential that the platform team can quickly push new versions. In this case, having Docker already facilitates this because simply uploading new versions to the Docker repository makes them available to our users.<br />On the other hand, to streamline the update process, what has worked well for us is to include an option in the execution script/wrapper to check and download new versions.<br />Initially, we made it so that each execution would check for new versions, but we found that it caused too much delay during startup, so now we prefer to let the user decide when to update.</div><p><br /></p><h3 style="text-align: left;">Conclusions:</h3><p></p><ul style="text-align: left;"><li>Docker allows packaging applications with specific versions in a controlled environment.</li><li>Creating a cross-platform wrapper in Go is an excellent solution to eliminate friction in the distribution and execution of tools implemented using Docker.</li><li>Investing in making installation and updating simple allows tools to evolve rapidly without generating much friction.</li></ul><p></p><div><br /></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-25873026331075919852023-11-15T19:11:00.002+01:002023-11-15T19:11:43.762+01:00Updated My Personal Mission. Same Essence, Different Words<p> </p><h2><b>Eduardo Ferro's Personal Mission</b></h2><div><b>Cultivate Happiness: </b>Foster personal joy and spread happiness to those around me, starting with family and friends, while continuously expanding my circle of influence.</div><div><br /></div><div><h4><b>Methods of Achievement</b></h4><div><ul><li><b>Responsibility and Respect: </b>Uphold personal accountability and respect for others in all interactions.</li><li><b>Balance Seeking: </b>Strive for a harmonious balance in personal life and contribute towards global equilibrium.</li><li><b>Authenticity: </b>Remain true to myself in every aspect of life, including professional pursuits.</li><li><b>Value Generation: </b>Utilize my abilities to create both intrinsic and economic value, mindful of social and ethical considerations.</li><li><b>Win-Win Scenarios: </b>Continually seek outcomes that are mutually beneficial.</li><li><b>Continuous Learning: </b>Embrace lifelong learning, both personally and professionally.</li><li><b>Conscious Decision-Making: </b>Choose my reactions and actions thoughtfully.</li></ul></div><h4><b>Ethical Stance</b></h4><div><b>Selective Engagement: </b>Refrain from involvement with businesses that conflict with my values, including:</div><div><ul><li>Financial enterprises that prioritize profit over social and environmental responsibility.</li><li>Weapon manufacturers and the military industry.</li><li>Casinos and gambling enterprises.</li><li>Entities involved in the abuse or exploitation of humans, animals, or the environment.</li><li>Businesses that negatively impact the lives of stakeholders.</li></ul></div></div><div><b><br /></b></div><h4>Vision for the Future</h4><div><div>I believe we are at a pivotal moment where our actions can significantly impact the planet, both positively and negatively. It's crucial to remember this responsibility at all times. We are amidst a revolution that blends collaboration, knowledge, and a federation of power. Networks are becoming the structures of the future, and their growth should be both sustained and sustainable.</div><div><br /></div><h4>Professional Alignment</h4><div>My focus is on engaging with green and teal organizations, where people are valued as the primary asset. I am drawn to environments that prioritize sustainable and ethical practices, recognizing the importance of human capital in driving positive change.</div><div><br /></div><h4>Personal Commitment</h4><div>I engage with the world passionately and responsibly, yet always at a measured pace, ensuring a balanced approach in all my endeavors.</div></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-65544510939249436862023-11-12T20:56:00.002+01:002023-11-12T23:19:15.612+01:00Learning lean/Agile concepts / short videos<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhS2Iznwb_qMk3LIlpDYaxfwKOeqSXEEfIXcfH-d4XUzLw-2Jn9xqrY8Dx-fdlPr7zGC4H40uZS_dDjhpVTeotczTK8ia29yGU598WfQ8tVb6UNCAIC56Gu9my6hdWoVeXvaEdjWwT15Obzck_NWe-zF62ib8WCkBNqvAgF0Z2PSru-Hh8KLcHc/s1024/lean_concepts.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1024" data-original-width="1024" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhS2Iznwb_qMk3LIlpDYaxfwKOeqSXEEfIXcfH-d4XUzLw-2Jn9xqrY8Dx-fdlPr7zGC4H40uZS_dDjhpVTeotczTK8ia29yGU598WfQ8tVb6UNCAIC56Gu9my6hdWoVeXvaEdjWwT15Obzck_NWe-zF62ib8WCkBNqvAgF0Z2PSru-Hh8KLcHc/w200-h200/lean_concepts.png" width="200" /></a></div><br /><p></p>
<div><div>Yesterday, my colleague <a href="https://twitter.com/cristina_verdi">Cristina Verdi</a> asked for interesting resources to help introduce Lean Software / Product Development concepts.</div><div>I passed her a series of <b>short videos</b> that I always use to illustrate certain related concepts. I'm posting them here in case they can help someone.</div></div><div><b><br /></b></div><div>
<b>Resource Efficiency vs Flow Efficiency:</b>
<ul style="text-align: left;">
<li><a href="https://www.youtube.com/watch?v=hGJpez7rvc0">The Efficiency Paradox</a> (18m) by <a href="https://niklasmodig.com/">Niklas Modig</a></li>
<li><a href="https://www.youtube.com/watch?v=CostXs2p6r0">The resource utilization trap</a> (5m) by <a href="https://twitter.com/henrikkniberg">Henrik Kniberg</a></li></ul>
</div>
<div>
<b>WIP Limits:</b>
<ul style="text-align: left;">
<li><a href="https://www.youtube.com/watch?v=Yqi9Gwt-OEA">Multiple WIP vs One Piece Flow Example</a> (7m) by <a href="https://twitter.com/henrikkniberg">Henrik Kniberg</a></li>
</ul>
</div>
<div>
<b>General processes / Team Work:</b>
<ul>
<li><a href="https://www.youtube.com/watch?v=NGdx-f-aGXs">Creating Value and Flow in Product Development</a> (7m) by <a href="https://twitter.com/johncutlefish">John Cutler</a> </li>
<li><a href="https://www.youtube.com/watch?v=FOLDDe4ARRs">Stop starting and start finishing</a> (5m) <a href="https://www.linkedin.com/in/jasonyip/">Jason Yip</a></li>
<li><a href="https://www.youtube.com/watch?v=KR7Y8IUgyyA">Making Work Visible: How to Unmask Capacity Killing WIP</a> (29m) <a href="https://twitter.com/dominicad">Dominica DeGrandis</a> </li>
</ul><div><br /></div>
</div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-60609162716119351812023-11-01T12:00:00.002+01:002023-11-01T12:00:08.301+01:00Harnessing Efficiency: The Theory of Constraints in Software Development<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghYMjn7eoZW_dGt3ySCsZMNmr6-ZhevfBUI_Zl4TM5-OveTXVDuOiw6nR3kPPU6C4TyxYkR6Y8_IpxQAMDXLEIpdFJt5y9Wo7WI44ioyr9jiTnfVHPdSmcxgYnLCbuwMVhzYGosueLe0OWJDVR8PgwotBV3RtDi85zZYGVwSfZByZbVsmM-kMy/s800/bottleneck.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="554" data-original-width="800" height="222" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghYMjn7eoZW_dGt3ySCsZMNmr6-ZhevfBUI_Zl4TM5-OveTXVDuOiw6nR3kPPU6C4TyxYkR6Y8_IpxQAMDXLEIpdFJt5y9Wo7WI44ioyr9jiTnfVHPdSmcxgYnLCbuwMVhzYGosueLe0OWJDVR8PgwotBV3RtDi85zZYGVwSfZByZbVsmM-kMy/s320/bottleneck.jpeg" width="320" /></a></div><br /><p><br /></p><span style="font-size: x-small;">This micro post was previously published at </span><a href="https://www.linkedin.com/posts/eferro_theoryofconstraints-softwaredevelopment-continuousimprovement-activity-7124434135397351424-sigc?utm_source=share&utm_medium=member_desktop" style="font-size: x-small;">linkedin</a><div><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Navigating the multi-faceted domain of software development often presents a series of bottlenecks that could hinder project momentum and delivery timelines. The Theory of Constraints (TOC) serves as a beacon, guiding teams to identify, address, and overcome these bottlenecks, thereby unlocking a pathway to streamlined processes and enhanced productivity.</span><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Here's a snapshot of how TOC unfolds in software development:</span><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><ol style="text-align: left;"><li><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> Identify the most important Constraint: Pinpoint the process, resource, or technology bottleneck obstructing progress (lack of quality, knowledge silos, convoluted deployment process, individual ownership about parts of the code or processes, etc.).</span></li><li><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Exploit the Constraint: Maximize the efficiency of the identified constraint without additional resources (reducing the WIP, redirecting people to help with the bottleneck, etc.).</span></li><li><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Subordinate Everything Else to the Constraint: Ensure all other processes are aligned to support and work around the constraint.</span></li><li><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Elevate the Constraint: Allocate necessary resources to alleviate or eliminate the constraint, promoting better throughput (investing in automation, test automation, pair/ensemble programming to spread knowledge, feature toggles to reduce risk, etc.).</span></li><li><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Repeat the Process: Embark on a cycle of continuous identification and resolution of constraints to foster a culture of ongoing improvement.</span></li></ol><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">For a deeper dive into TOC and its application in IT landscapes, <a href="https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271951">'The Goal'</a> by Eliyahu M. Goldratt </span><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">and <a href="https://itrevolution.com/product/the-phoenix-project/">'The Phoenix Project'</a> by </span><a data-attribute-index="1" data-entity-type="MINI_PROFILE" href="https://www.linkedin.com/in/ACoAAADYECUBlA7fZx5GCx9Ss7G1dx67Drqd47A" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">Gene Kim</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">, </span><a data-attribute-index="3" data-entity-type="MINI_PROFILE" href="https://www.linkedin.com/in/ACoAAAACYKQBZPywPPmgw-1SlQXhFaz3SKIMcm4" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">Kevin Behr</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">, and </span><a data-attribute-index="5" data-entity-type="MINI_PROFILE" href="https://www.linkedin.com/in/ACoAAAAODhwBOtKmoTN8QWbHnCLJgllTNXAn1N0" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">George. Spafford</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> </span><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">are essential reads.</span></div><div><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Using the Theory of Constraints (TOC) can help software development professionals and teams deal with problems smartly. It helps turn these problems into opportunities for improvement, growth and faster delivery.</span><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">Indeed, the Theory of Constraints relates to Lean Software Development and agile software development methodologies.</span><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">The lightning talk <a href="https://www.youtube.com/watch?v=FOLDDe4ARRs">"Stop Starting and Start Finishing"</a> </span><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;">by </span><a data-attribute-index="9" data-entity-type="MINI_PROFILE" href="https://www.linkedin.com/in/ACoAAAA8un4BlXzmBee34JtnjreXcQfQr-fV08c" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">Jason Yip</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> is one of the best explanations I know for understanding how to use TOC and other Lean ideas to optimize the sustained delivery flow of a software development team.</span><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><br style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; box-sizing: inherit; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; line-height: inherit !important;" /><a data-attribute-index="11" href="https://www.linkedin.com/feed/hashtag/?keywords=theoryofconstraints&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7124434135397351424" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">#TheoryOfConstraints</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> </span><a data-attribute-index="12" href="https://www.linkedin.com/feed/hashtag/?keywords=softwaredevelopment&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7124434135397351424" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">#SoftwareDevelopment</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> </span><a data-attribute-index="13" href="https://www.linkedin.com/feed/hashtag/?keywords=continuousimprovement&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7124434135397351424" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">#ContinuousImprovement</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> </span><a data-attribute-index="14" href="https://www.linkedin.com/feed/hashtag/?keywords=thegoal&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7124434135397351424" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">#TheGoal</a><span style="background-color: white; color: rgba(0, 0, 0, 0.9); font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px;"> </span><a data-attribute-index="15" href="https://www.linkedin.com/feed/hashtag/?keywords=leansoftwaredevelopment&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7124434135397351424" style="--tw-border-spacing-x: 0; --tw-border-spacing-y: 0; --tw-ring-color: rgb(59 130 246 / 0.5); --tw-ring-offset-color: #fff; --tw-ring-offset-shadow: 0 0 #0000; --tw-ring-offset-width: 0px; --tw-ring-shadow: 0 0 #0000; --tw-rotate: 0; --tw-scale-x: 1; --tw-scale-y: 1; --tw-scroll-snap-strictness: proximity; --tw-shadow-colored: 0 0 #0000; --tw-shadow: 0 0 #0000; --tw-skew-x: 0; --tw-skew-y: 0; --tw-translate-x: 0; --tw-translate-y: 0; background-color: white; border: var(--artdeco-reset-link-border-zero); box-sizing: inherit; font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", "Fira Sans", Ubuntu, Oxygen, "Oxygen Sans", Cantarell, "Droid Sans", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Lucida Grande", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: var(--font-weight-bold); line-height: inherit !important; margin: var(--artdeco-reset-base-margin-zero); overflow-wrap: normal; padding: var(--artdeco-reset-base-padding-zero); position: relative; text-decoration: var(--artdeco-reset-link-text-decoration-none); touch-action: manipulation; vertical-align: var(--artdeco-reset-base-vertical-align-baseline); word-break: normal;">#LeanSoftwareDevelopment</a></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-90471667872902359412023-11-01T10:37:00.003+01:002023-11-01T10:37:58.700+01:00The virtuous loop of software development<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLCkqz4mt8yCMXiV6NfURqQM7sXxarQxSJodohqQH7DwaIUNHnLPGP8g8qRAO3JIE3dsU9ddlXnIW2GAYfNxm_O_9LlKpIH0u-3KdaNUoXz-MzFD-VEfwp5Pob3eKxW1jG72SMg1_cjOj23EIaJU_svfAc-xl7I0ktn0R-Sf18kr8WuTSIQdkz/s800/blog1.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="425" data-original-width="800" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLCkqz4mt8yCMXiV6NfURqQM7sXxarQxSJodohqQH7DwaIUNHnLPGP8g8qRAO3JIE3dsU9ddlXnIW2GAYfNxm_O_9LlKpIH0u-3KdaNUoXz-MzFD-VEfwp5Pob3eKxW1jG72SMg1_cjOj23EIaJU_svfAc-xl7I0ktn0R-Sf18kr8WuTSIQdkz/s320/blog1.jpeg" width="320" /></a></div><br /><div><br /></div><div><span style="font-size: xx-small;">This micro post was previously published at <a href="https://www.linkedin.com/posts/eferro_softwaredevelopment-continuousdelivery-activity-7121790331670474752-sRTc?utm_source=share&utm_medium=member_desktop">linkedin</a></span></div><div><br /></div>
The ultimate aim is Continuous Delivery (CD), a goal that enables fast flow with rapid iterations and continuous feedback. At the same time, this goal promotes technical excellence and good design.<div><br /></div><div>Continuous Integration (CI) is required (integrating at least once a day, also known as Trunk Based Development), along with a strong focus on Test-Driven Development (TDD) or other similar practices to ensure high confidence and emphasis on excellent and simple design.
This approach is closely linked to Extreme Programming and the DevOps mindset, which emphasizes collaboration and continuous improvement. By following these principles, software development teams can enhance their efficiency and deliver high-quality products to customers.</div><div><br /></div><div><br /></div><div>Here are some related resources that you might find interesting:</div><div><ul style="text-align: left;"><li><a href="https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912">Continuous Delivery book</a> by Jez Humble and Dave Farley</li><li><a href="https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658">Extreme Programming Explained book</a> by Kent Beck</li><li><a href="https://www.youtube.com/c/ContinuousDelivery">Continuous Delivery YouTube channel</a> by Dave Farley</li><li><a href="https://www.amazon.com/exec/obidos/ASIN/0321150783/poppendieckco-20">Lean Software Development</a> by Mary and Tom Poppendieck</li><li><a href="https://www.geepawhill.org/series/many-more-much-smaller-steps/">Many More Much Smaller Steps (MMMSS)</a> by GeePaw Hill</li><li><a href="https://www.geepawhill.org/2021/11/16/mmmss-the-intrinsic-benefit-of-steps/">MMMSS – The Intrinsic Benefit of Steps</a> by GeePaw Hill </li><li><a href="https://minimumcd.org/">Minimum Viable CD</a> </li></ul></div><div><br /></div><div><br /></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-27292852893648375232023-10-16T13:45:00.001+02:002023-10-16T13:51:32.799+02:00Good talks/podcasts (Oct 2023 I)<div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7Ux1lfYtPW7wRyWRfaGExqOqUMX1pMRlHEUgUzM-fhytu9CaOQ9bHZP_LGKhxSUnXafZgt5tf2naPpiS42eGwFc73lA9wp2EQu0uzk5PvZCMvnb28p2fhebOpnk1WwzIfMGTIc6C_PYREQckVMI1RjCi-8xVjwBWE2vCnVXavPX4OzW4fAzOn/s1792/speaker.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="1024" data-original-width="1792" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7Ux1lfYtPW7wRyWRfaGExqOqUMX1pMRlHEUgUzM-fhytu9CaOQ9bHZP_LGKhxSUnXafZgt5tf2naPpiS42eGwFc73lA9wp2EQu0uzk5PvZCMvnb28p2fhebOpnk1WwzIfMGTIc6C_PYREQckVMI1RjCi-8xVjwBWE2vCnVXavPX4OzW4fAzOn/s320/speaker.png" width="320" /></a></div><div><br /></div>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=z8wcRDqtyRs">The Elegant Solution: Toyota's Formula for Mastering Innovation</a>
<b>(Matthew May)</b>
<b>[Lean, Lean Manufacturing]</b>
<b>[Duration: 1:15:00]</b>
Interesting presentation on how Toyota incorporates continuous learning and innovation into the company's daily operations.
</li>
<li>
<a href="https://www.youtube.com/watch?v=F87PtAoJNtg">"Simple Made Easy" (12-minute redux) by Rich Hickey (2011)</a>
<b>(Rich Hickey)</b>
<b>[Architecture, Inspirational, Scalability, Software Design]</b>
<b>[Duration: 0:12:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
This is a 12-minute redux of the 1-hour talk by Rich Hickey, for really impatient people. Original: https://www.youtube.com/watch?v=SxdOUGdseq4
</li>
<li>
<a href="https://www.youtube.com/watch?v=uzc6p3qvH_k">Infrastructure as actual Code • YOW! 2022</a>
<b>(Gregor Hohpe)</b>
<b>[Architecture, Architecture patterns, Infrastructure, Serverless]</b>
<b>[Duration: 0:59:00]</b>
This talk shares recent trends in infrastructure automation, debunks some common misconceptions, and shows you how you can combine AWS’ serverless ecosystem and AWS CDK to rethink application development, deployment, and integration.
</li>
<li>
<a href="https://www.youtube.com/watch?v=qjZ2_ZLorjQ">Lean Turned Up to 10</a>
<b>(Chris Lucian, Austin Chadwick)</b>
<b>[Lean Software Development, MobProgramming, Technical Practices]</b>
<b>[Duration: 0:58:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Chris and Austin explain why mob programming could be a way to implement lean software development in current teams. Very interesting.
</li>
<li>
<a href="https://www.youtube.com/watch?v=G2X_7ojZwtU">LKUK13: Cynefin in Action - Liz Keogh</a>
<b>(Liz Keogh)</b>
<b>[Culture, Engineering Culture, Inspirational]</b>
<b>[Duration: 0:51:00]</b>
In this talk Liz explains the Cynefin framework and other concepts as Real Options, Deliberate Discovery, Feature Injection, etc.
</li>
</ul>
<b>Reminder:</b> All of these talks are interesting, even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-23392649883129271682023-10-15T11:10:00.002+02:002023-10-15T11:10:44.806+02:00The Art of Small Steps in Software Development: A Lean Vision<p>Have you ever played Tetris? If so, you know that every decision, every piece, and every move counts. The same applies to software development. Every choice, every line of code, and every interaction influences the final outcome. This post will explore how Lean software development and the "safe small steps" approach can simplify complexity and create efficient systems.</p><h3 style="text-align: left;">Small Steps: The Simplicity of Tetris</h3><p>Just like in Tetris, where we choose where to place small pieces to complete lines, in software development, we continuously make decisions about how to build our product. These decisions, when made in small increments, allow us to:</p><p></p><ul style="text-align: left;"><li><b>Iterate quickly</b>: Fixes and adjustments are simpler.</li><li><b>Reduce risks</b>: We limit potential errors at each stage.</li><li><b>Understand better</b>: Each step is understood and analyzed more clearly.</li></ul><p></p><h3 style="text-align: left;">Principles of Lean Software Development</h3><p>Based on Lean philosophy, Lean software development focuses on maximizing customer value and minimizing waste. Some of the key principles include:</p><p></p><ul style="text-align: left;"><li><b>Reduce waste</b>: Eliminate the unnecessary and focus on the essentials. Every step must add value or increase the internal or external quality of the product.</li><li><b>Decide as late as possible</b>: Be flexible and adapt to changes. See <a href="https://www.eferro.net/2022/08/software-development-art-of-postponing.html">Lean Software development: The art of postponing decisions</a>.</li><li><b>Deliver quickly</b>: Allows for feedback and adaptation to customer needs.</li><li><b>Build with integrity and quality</b>: Ensures a reliable and long-lasting product. This is key to maintaining speed sustainably over time.</li><li><b>Proactively simplify</b>: Avoid unnecessary complexity and keep the system manageable. Simplification also adds value, protecting the current value and avoiding future costs.</li></ul><p></p><h3 style="text-align: left;">Small Steps: The Simplicity and Continuity of Tetris</h3><p>Tetris, one of the most iconic video games in history, presents us with a continuous and infinite challenge. In it, pieces of different shapes fall from the top of the screen at an increasing speed. Our task is to accommodate these pieces efficiently at the bottom, trying to fit them so that they complete horizontal lines. Completing these lines eliminates them, granting us points and, more importantly, space to continue playing.</p><p>In Tetris, value accumulates by adding points, piece by piece, line by line. However, the real challenge and essence of the game lie in balancing the accumulation of that value (points) while managing increasing complexity (the accumulated pieces). If we allow the pieces to pile up and reach the top of the screen, we lose the game.</p><p>Similarly, in software development, we continuously decide how to build our product. Like in Tetris, we must accumulate value (features and characteristics) while managing and keeping complexity at bay. These decisions, when made in small increments or "steps," allow us to:</p><p></p><ul style="text-align: left;"><li>Iterate quickly: Fixes and adjustments are simpler.</li><li>Reduce risks: We limit potential errors at each stage.</li><li>Understand better: Each step is understood and analyzed more clearly.</li></ul><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5HlOPu9yFLBr885kETuJh-W0hk5KWsn4pxNO1xoXeSpkucFrykOiRkkp5uc2t7edYSgXkXrg5fpIme1Q3EQ0QOofJsTdHWRRUPJkHQbaqFL73K72iSIQ4VoWICUllYtlx_4VnrGU7vVR9vAxBbIZQ5oWIDz0evjBno7d2LA7Z3v2ZyZDaTuyC/s1299/tetris1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="728" data-original-width="1299" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5HlOPu9yFLBr885kETuJh-W0hk5KWsn4pxNO1xoXeSpkucFrykOiRkkp5uc2t7edYSgXkXrg5fpIme1Q3EQ0QOofJsTdHWRRUPJkHQbaqFL73K72iSIQ4VoWICUllYtlx_4VnrGU7vVR9vAxBbIZQ5oWIDz0evjBno7d2LA7Z3v2ZyZDaTuyC/s320/tetris1.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Tetris / Larger vs Smaller pieces</td></tr></tbody></table><p>Just like playing with large pieces in Tetris, working with large steps in software development makes the game/work much more difficult and stressful.</p><h3 style="text-align: left;">Conclusion</h3><p>Software development is not just about writing code; it's about making informed and continuous decisions to create valuable products. Just like in Tetris, every piece, every step, counts. Embrace the Lean philosophy and focus on safe small steps to simplify, adapt, and deliver with quality.</p><div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj09tIbZBdmhKMZm_eRaDrb_dooxW1eLXebR6dkZdoAe9S57ZpC02f_CaQnOrqplqPGem3-gURqc9hjbpuCMOhZauB75HGG-7Ox7I2tNnRSAZCbXQEcw2tnxXptRp7L9zddV5tVIMHFpToa80nG7sTsttuKLpBpVEkST2QBl8or3SgQfqbhIFIa/s1299/tetris_lean.png" imageanchor="1"><img border="0" data-original-height="728" data-original-width="1299" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj09tIbZBdmhKMZm_eRaDrb_dooxW1eLXebR6dkZdoAe9S57ZpC02f_CaQnOrqplqPGem3-gURqc9hjbpuCMOhZauB75HGG-7Ox7I2tNnRSAZCbXQEcw2tnxXptRp7L9zddV5tVIMHFpToa80nG7sTsttuKLpBpVEkST2QBl8or3SgQfqbhIFIa/s320/tetris_lean.png" width="320" /></a></div><p>If this approach has intrigued you, I invite you to delve deeper into <b>Lean software development</b> and experience how it can transform your development process.</p><div><h3>Related:</h3></div><div><ul style="text-align: left;"><li><a href="http://www.poppendieck.com/">http://www.poppendieck.com/</a></li><li><a href="https://www.amazon.com/stores/Mary-Poppendieck/author/B001IGNU3O">Lean Software Development books</a> </li><li><a href="https://www.eferro.net/2022/08/software-development-art-of-postponing.html">Lean Software development: The art of postponing decisions</a></li></ul></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-19810924243520714952023-10-06T20:13:00.001+02:002023-10-17T14:56:34.891+02:00DevOpsDays Madrid: The Complexity Trap Reevaluating our incentives<p> I've had the pleasure of being invited to give a Keynote at the <a href="https://devopsdays.org/events/2023-madrid/">DevOpsDays Madrid</a> event.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjLVJOgyGLWjlahSRLa20DQg3jcyU_x_N4D3ZAIR5xTAmn0hl2jvOm8E3UNfIE9u0NkgdV6owCUX4IatZ-5KWq146u097LdUec9W4-hMc6ZkwMNP-kAsIisPfs8u7wQzJPIUQpGg_BcDGAsJ208qoz3snG-ILFyEX8hcq9LdnuIjYTm6kv1i9C/s2400/logo.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="2400" data-original-width="2400" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjLVJOgyGLWjlahSRLa20DQg3jcyU_x_N4D3ZAIR5xTAmn0hl2jvOm8E3UNfIE9u0NkgdV6owCUX4IatZ-5KWq146u097LdUec9W4-hMc6ZkwMNP-kAsIisPfs8u7wQzJPIUQpGg_BcDGAsJ208qoz3snG-ILFyEX8hcq9LdnuIjYTm6kv1i9C/s320/logo.png" width="320" /></a></div><p><br />I'm leaving the slides and some interesting related references here.</p><p></p><h3 style="text-align: left;">The Complexity Trap Reevaluating our incentives</h3><div><br /></div>
<div>Video (Spanish):</div>
<p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/wqHo44xrc9I?si=QLLW9zOJmtlHNRaX" title="YouTube video player" width="560"></iframe>
</p>
<p><a href="https://www.youtube.com/watch?v=wqHo44xrc9I">Youtube video</a></p>
<div>Thanks to <a href="https://www.autentia.com/">Autentia</a> for the recording of the session.</div><div>You can watch the sessions of the conference and other conferences on their channel <a href="https://www.youtube.com/@AutentiaMedia">https://www.youtube.com/@AutentiaMedia</a> </div><div><br /></div><div><br /></div>Slides:<p></p>
<iframe allowfullscreen="true" frameborder="0" height="569" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/e/2PACX-1vS2E5GUKXUrW5KQVBNr7ZTzgq5LLi6eqeOQrF-PWCVWU1Qn015a-YgRnKt1-x1Ku-LGPW6Dgck-ahrJ/embed?start=false&loop=false&delayms=3000" webkitallowfullscreen="true" width="960"></iframe><p><a href="https://docs.google.com/presentation/d/1mpEHeIY0wYJc8LoDMdoJ582U7MxwkJSlx-onJ0Jow98/edit?usp=sharing">Original document</a></p><h3 style="text-align: left;">Related Quotes:</h3><div><div><ul style="text-align: left;"><li>"Art is the elimination of the unnecessary." Pablo Picasso</li><li>"Code is cost, and production code is by far the higher cost. If you can write more support code (tests, automation, developer tooling) in order to write less&better production code more smoothly, Win!" @jessitron</li><li>"Code is liability. To build something is to be responsible for its existence, forever. Write more software only as a last resort." @mipsytipsy</li><li>"Complexity is what makes software hard to change. That, and duplication." Ralph Johnson</li><li>"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." - Alan Perlis</li><li>"If you don’t actively fight for simplicity in software, complexity will win…and it will suck." Henrik Joreteg</li><li>"irreversibility was one of the prime drivers of complexity" Enrico Zaninotto</li><li>"Keep it simple, make it valuable, build it piece by piece" Ron Jeffries</li><li>"My position is that code, pretty much exclusively, is cost. It’s all liability. The asset is what it does. So, if I can get simpler code that does the same thing, I’ll take the simpler code. If I can have no code and get the same capability, I’ll take no code. No code is better than some code, some code is better than lots of code!" Dan North @tastapod</li><li>"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." Edsger W. Dijkstra</li><li>"Simplicity is the ultimate sophistication" Leonardo da Vinci</li><li>"Simplicity--the art of maximizing the amount of work not done--is essential." Principles behind the Agile Manifesto</li><li>"Software maintenance is not "keep it working like before." It is "keep being useful in a changing world"" Jessitron</li><li>"The art of programming is the art of organizing complexity." Edsger W. Dijkstra</li><li>"The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing." Mary Poppendieck</li><li>"The faster you build crap the more crap you get" Jeff Patton</li><li>"The old truths: Keep it simple, Make it small, Make it correct, Fight complexity" Joe Armstrong</li></ul></div></div><div><br /></div><h3 style="text-align: left;">Related / References:</h3><li><a href="https://www.youtube.com/watch?v=Ed94CfxgsCA">The art of destroying software (Greg Young)</a></li><li><a href="https://www.eferro.net/2017/10/simplicidad-para-desarrolladores.html">Simplicidad para desarrolladores (Spanish)</a></li><li><a href="https://www.eferro.net/2021/02/basal-cost-of-software.html">Basal Cost of Software</a></li><li><a href="https://www.infoq.com/presentations/8-lines-code-refactoring/">8 lines of code</a></li><li><a href="https://www.infoq.com/presentations/complexity-simplicity-esb/">Complexity Is Outside the Code</a> </li><li><a href="https://www.infoq.com/presentations/Simplicity-Architect/">Simplicity, The Way of the Unusual Architect</a> </li><li><a href="https://www.infoq.com/presentations/Simple-Made-Easy/">Simple-Made-Easy/</a></li><p><br /></p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-28884807722436638902023-08-26T23:56:00.003+02:002023-08-27T00:03:15.899+02:00Good talks/podcasts (Ago 2023 I)
<div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEcJlWno_mco9tgNdRslctOIBGa-54yWZNJHletpfWSDhoYrQlx6FcJEeW7Gp7XqwTs2x4raxDIYbCIf1WU0-9nmoT_ajqInQyaba3hvQvgbCwKy9owI3-ZkGIMjibk9f7eXly4by5e3-MddMABwYCrcjdzjm3Gct2k_q02huEHpJ4VnaI8uUM/s325/learning.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="187" data-original-width="325" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEcJlWno_mco9tgNdRslctOIBGa-54yWZNJHletpfWSDhoYrQlx6FcJEeW7Gp7XqwTs2x4raxDIYbCIf1WU0-9nmoT_ajqInQyaba3hvQvgbCwKy9owI3-ZkGIMjibk9f7eXly4by5e3-MddMABwYCrcjdzjm3Gct2k_q02huEHpJ4VnaI8uUM/s320/learning.png" width="320" /></a></div>
<p> </p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=kJdXjtSnZTI">Simon Sinek Performance vs Trust</a>
<b>(Simon Sinek)</b>
<b>[Company Culture, Culture, Inspirational]</b>
<b>[Duration: 2:21]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Great description of the impact of trust on team members and leaders.
</li>
<li>
<a href="https://www.youtube.com/watch?v=kKbQ2-dXsmE">CONSTANT Changes To User Requirements Drive Me CRAZY</a>
<b>(Dave Farley)</b>
<b>[Agile, Continuous Delivery, Inspirational, Lean Product Management, Lean Software Development]</b>
<b>[Duration: 0:13:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
This presentation by Dave Farley shows that software development is not just about translating perfect requirements into code, but rather a process of discovery and exploration. It acknowledges that the nature of the problems being solved has changed and that it is impossible to have all the answers. It emphasizes that successful software products must be able to adapt and evolve over time, and that the key to success is embracing change and making it easy, safe, and low-cost.
</li>
<li>
<a href="https://www.youtube.com/watch?v=rP7bpYsfa6Q">Tips For Technical Startup Founders | Startup School</a>
<b>(Diana Hu)</b>
<b>[Inspirational, Lean Software Development, Lean Startup, startup]</b>
<b>[Duration: 0:28:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Diana Hu shares her advice for being a technical founder at the earliest stages - including topics like how to ship an MVP fast, how to deal with technology choices and technical debt, and how and when to hire an engineering team.
</li>
<li>
<a href="https://www.youtube.com/watch?v=XG4HxI1hZOA">Scaling Shape Up Beyond Bootstrapped Companies</a>
<b>(Ryan Singer)</b>
<b>[Product, Product Leadership, Product Strategy]</b>
<b>[Duration: 0:47:00]</b>
Interesting talk about the ShapeUp product development methodology and how it can be used in different contexts. Very interesting ideas even if you don't use ShapeUp.
</li>
<li>
<a href="https://www.youtube.com/watch?v=_oHiyunEMF0">AI Impacts in Development Practice</a>
<b>(Michael Feathers)</b>
<b>[AI, Devex]</b>
<b>[Duration: 0:33:00]</b>
Interesting reflections on how the profession of software developer might evolve with the introduction of AI (LLMs, GenAI). Among other topics, Michael talks about the importance of quality in this environment, the adaptation of practices like TDD, and the need to specify precise requirements, etc.
</li>
<li>
<a href="https://www.youtube.com/watch?v=sc3J4McebHE">FAST '23 - Building and Operating a Pretty Big Storage System (My Adventures in Amazon S3)</a>
<b>(Andy Warfield)</b>
<b>[Engineering Culture, Engineering Scalability, Scalability]</b>
<b>[Duration: 0:53:00]</b>
he perspective of evolution, design, and team organization in the context of rapid growth and at a scale hard to imagine.
</li>
<li>
<a href="https://www.youtube.com/watch?v=9Q7GANXn02k">Minimum Viable Architecture</a>
<b>(Randy Shoup)</b>
<b>[Architecture, Architecture patterns, Evolutionary Architecture]</b>
<b>[Duration: 0:47:00]</b>
Presentation on 'Minimal Viable Architecture', discussing its evolution alongside a product's lifecycle phases: idea, start, scale, and optimize. Each phase examines business goals, constraints, and suggests corresponding software architecture.
</li>
<li>
<a href="https://www.youtube.com/watch?v=a_T21Lf26pc">Artificial Intelligence seen from the software development lifecycle perspective</a>
<b>(Nerea Luis)</b>
<b>[AI, MLOps]</b>
<b>[Duration: 0:54:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Great introduction to the differences between traditional software development and the development cycle with AI models. Nerea introduces concepts such as Continuous training, model deployment, MLOps, and collaboration between data scientists and software engineers. Highly recommended for software engineers looking to delve into these topics and collaborate more closely on AI-based feature development.
</li>
</ul>
<b>Reminder:</b> All of these talks are interesting, even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-79506944585511865452023-08-15T22:17:00.003+02:002023-08-21T14:53:01.204+02:00Why Lean Product Development is Essential for Effective Product Teams<p> In today's fast-paced and competitive business landscape, it is crucial for companies to have effective product teams that can deliver high-impact solutions. However, many product teams often struggle to achieve this goal due to various challenges and constraints. In this blog post, we will explore the importance of lean product development from the perspective of engineering and how it can enable effective product teams. We will also discuss the role of system architecture in facilitating product delivery&discovery and highlight some common pitfalls that hinder the success of product teams.</p><h2 style="text-align: left;">The Risks of Product Development</h2><p>Before diving into the details, let's first understand the risks associated with product development. According to a blog post by <a href="https://twitter.com/cagan">Marty Cagan</a>, there are four major risks: value, usability, feasibility, and business viability.</p><p></p><ul style="text-align: left;"><li><b>Value:</b> Will customers buy or use our software? This risk pertains to whether the customer sees value in the product and is willing to adopt it.</li><li><b>Usability:</b> Can users figure out how to use the software? This risk focuses on the user experience and whether the software is intuitive and easy to use.</li><li><b>Feasibility:</b> Can our engineers build the software within the given constraints? This risk considers the technical feasibility of implementing the desired features.</li><li><b>Business Viability:</b> Does the solution align with the overall business strategy and goals? This risk examines whether the solution is viable from a business perspective.</li></ul><p></p><p>It is important to address these risks to ensure the success of a product. However, many product teams often overlook or underestimate these risks, leading to failures and wasted resources.</p><h2 style="text-align: left;">Learning from Industry Leaders</h2><p>To emphasize the significance of lean product development, let's take a look at some insights from industry leaders. Microsoft conducted research on their own product development process and found that only one-third of their ideas actually improved metrics. Similarly, Amazon's success rate was below half of their ideas. These findings highlight the importance of validating ideas and the need to filter out ineffective ones.</p><p>It is crucial to recognize that even highly successful companies like Microsoft and Amazon face challenges in generating impactful ideas. Therefore, assuming that all ideas are great without proper validation can be detrimental to a product team's success.</p><p>Not only are many of the ideas not positive, but also the ones that are, require several iterations (with real feedback) to begin generating positive impact.</p><p><br /></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiWV_FYbiSAAl2NoKfuifP3y72r_xQujsIqcZCu15yTvcEgR_jITZBVresBjm4tt0-l6tVUDgcT8lzHSMdFMwEp-zd6THXw0s_RGLdfWMR_pozgpJK-hnDdnLGNZVa__0rnSX8imaPRO7oSHxJRmE6Z6LdS0cV6ilPbQKuFpJJrpcANUy3g8zlT" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="811" data-original-width="989" height="328" src="https://blogger.googleusercontent.com/img/a/AVvXsEiWV_FYbiSAAl2NoKfuifP3y72r_xQujsIqcZCu15yTvcEgR_jITZBVresBjm4tt0-l6tVUDgcT8lzHSMdFMwEp-zd6THXw0s_RGLdfWMR_pozgpJK-hnDdnLGNZVa__0rnSX8imaPRO7oSHxJRmE6Z6LdS0cV6ilPbQKuFpJJrpcANUy3g8zlT=w400-h328" width="400" /></a></div><br /><br /><p></p><h2 style="text-align: left;">The Vicious Cycle of Software Development</h2><p>To understand why lean product development is essential, we need to examine the vicious cycle of software development. In this cycle, a product team has a fixed capacity to develop software. While some features may generate positive impact, others may go unused or fail to meet user expectations. Additionally, the software incurs maintenance costs, such as debugging, monitoring, and infrastructure support (See: <a href="https://www.eferro.net/2021/02/basal-cost-of-software.html">Basal Cost of Software</a>).</p><p><b>Over time, the accumulation of software and its associated maintenance costs can deplete the team's capacity for innovation. This cycle hinders the team's ability to focus on high-impact initiatives and leads to a decrease in overall productivity.</b></p><p>Furthermore, the cost of maintaining software is not linear with its size. Doubling the size of an application does not double the maintenance cost; it increases it even more. This exponential increase in maintenance costs further limits the team's capacity for innovation.</p><h2 style="text-align: left;">Viewing Software as a Means to an End</h2><p>To break free from the vicious cycle of software development, it is crucial to view software as a means to an end rather than the end itself. Software should be seen as a liability and an expensive asset that should be minimized. The focus should be on maximizing outcomes, impact, and return on investment while minimizing functionality, requirements, and maintenance costs.</p><p>By adopting this mindset, product teams can prioritize high-impact initiatives and avoid wasting resources on unnecessary features. This shift in perspective enables teams to make better decisions and deliver more value to customers.</p><p>This way of thinking also helps protect against the Feature creep that many products suffer from.</p><div><h2 style="text-align: left;">Effective Product Teams and Lean Product Development</h2><div>To achieve high performance, product teams need to embrace effective lean product practices. These practices involve building the right thing and making the thing right.</div><div>Building the right thing involves minimizing the amount of software while maximizing the impact. It requires filtering out unnecessary ideas and focusing on initiatives that align with the overall business strategy. This approach ensures that the team's efforts are directed towards high-impact solutions.</div><div>Making the thing right involves continuous learning, hypothesis experiments, and user stories. It requires a collaborative team effort, with everyone involved in the product discovery&delivery process. By working together, teams can validate assumptions, reduce risks, and deliver elegant and impactful solutions.</div><div><br /></div><div>This process of continuous learning, filtering ideas, continuously experimenting, and delivering in small, safe steps that allow us to learn (through feedback), minimizing waste as much as possible, is what we would call Lean Product Development.</div></div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWtZm6fNRuVIsTSG4fkr80dMBZ0sL59OYq-hbhfDXmqmSdcqAsuoWXklbw-l1lXPg175639T9ksYghREIPSJPa_0_KYJVV-tsWxjDo58x8GTgY_nksiXu13O_FOQDVc8ov5sIfXvb78pDUYHR90AQZheXkC6GexGSoQLrjjz7pu73DQ09XpkVX/s1927/effective_teams.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1082" data-original-width="1927" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWtZm6fNRuVIsTSG4fkr80dMBZ0sL59OYq-hbhfDXmqmSdcqAsuoWXklbw-l1lXPg175639T9ksYghREIPSJPa_0_KYJVV-tsWxjDo58x8GTgY_nksiXu13O_FOQDVc8ov5sIfXvb78pDUYHR90AQZheXkC6GexGSoQLrjjz7pu73DQ09XpkVX/w640-h360/effective_teams.png" width="640" /></a></div><br /><div><br /></div><div><h2 style="text-align: left;">The Role of System Architecture</h2><div>System architecture plays a crucial role in facilitating lean product delivery. It should be designed to optimize learning, experimentation, and evolution. Here are some key considerations for system architecture:</div><div><ul style="text-align: left;"><li><b>Decoupling Release and Deployment:</b> To enable business-driven decisions, release should be decoupled from deployment. Feature flags can be used to control the release of new features and enable experimentation. This ability to release to a group of users independently enables the team to progressively validate hypotheses with different customer groups, thus managing the risk assumed in each case.</li><li><b>Product Instrumentation:</b> The system should be instrumented to gather relevant metrics and operational data. This data provides valuable insights into user behavior and helps in making informed decisions. Assuming that a team can be autonomous and make good decisions when flying blind and without instruments makes no sense. Product-level instrumentation and observability are not a luxury, but an essential part of any effective product team.</li><li><b>Operational Data Exploration:</b> It is essential to have systems in place to explore operational data effectively. This ensures that the collected data is utilized to its full potential and helps in identifying patterns and trends. This point complements the previous one; having good instrumentation is useless if it is not easy to exploit for making product decisions or learning about our users' behavior.</li><li><b>Safe-to-Learn Environment:</b> The system should provide a safe environment for experimentation and learning. A blameless culture should be fostered, where failures are seen as opportunities for improvement rather than as a cause for blame.</li><li><b>Modular/Decoupled Architecture:</b> A modular architecture enables multiple product teams to work autonomously on different parts of the system. It reduces the blast radius of failures and allows for more efficient development and maintenance. This architecture should also allow the team to easily compose new applications, proof of concepts, and demos based on the available modules and components. When the design quality is good, it is much easier to reuse components for experiments and as a basis for new use cases.</li></ul></div><div>By incorporating these architectural considerations, product teams can create an environment that enables continuous evolution, learning, and experimentation. Ultimately, it all comes down to having an adaptable system that we can trust and that is <b>optimized for making small, low-risk changes at high speed</b>.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEIm0uSvzlVm0ySsTdLPWRIANDK7Su7CHwhknJasodOzRtsYw8hQqeRzBenTdxHpcHH0UtEyZxkSvE9z3yao6TUSh-p9oYVuKBYq1OswdLCByGlTKP67pctILmOjl2eMuCJr1LSPWpzj8qPLWUuWNqJ8Nr8d_5L0UcmtPudD01W-Qd7WxQ1ho9/s1322/extensibility-prototyping.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="640" data-original-width="1322" height="310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEIm0uSvzlVm0ySsTdLPWRIANDK7Su7CHwhknJasodOzRtsYw8hQqeRzBenTdxHpcHH0UtEyZxkSvE9z3yao6TUSh-p9oYVuKBYq1OswdLCByGlTKP67pctILmOjl2eMuCJr1LSPWpzj8qPLWUuWNqJ8Nr8d_5L0UcmtPudD01W-Qd7WxQ1ho9/w640-h310/extensibility-prototyping.png" width="640" /></a></div><br /><div><br /></div><div><br /></div><div>Depending on the type of system, we can even include architecture decisions that specifically help us experiment and learn more quickly. For example, if it is a product that can be considered a platform, having all capabilities and use cases accessible through APIs can allow us to experiment and create prototypes very quickly using those endpoints from Low Code or No Code systems.</div></div><div><h2 style="text-align: left;">Overcoming Challenges and Maximizing Outcomes</h2><div>To build effective product teams, it is essential to address common challenges and pitfalls. Here are some key points to consider:</div><div><ul style="text-align: left;"><li><b>Autonomy and Decision-Making:</b> Product teams should have the autonomy to make decisions and generate ideas. Stakeholders should trust the expertise of engineers and involve them in the product discovery process.</li><li><b>Technical Debt and Stability:</b> Addressing technical debt and ensuring system stability are crucial for successful product delivery. Without a stable foundation, teams will struggle to innovate and deliver high-impact solutions.</li><li><b>Focus on Outcomes:</b> Engineers should shift their focus from technology to outcomes. The value and impact delivered to customers should be the primary concern, rather than the features or technology used.</li><li><b>Continuous Learning and Improvement:</b> Product teams should embrace a culture of continuous learning and improvement. This involves validating assumptions, running experiments, and constantly seeking feedback from customers and the system.</li><li><b>Collaboration and Ownership:</b> Effective product teams require collaboration and shared ownership. Product managers, designers, and engineers should work together as a cohesive unit, leveraging their respective expertise to deliver high-impact solutions.</li><li><b>Praise Continuous Impact and Learning:</b> To generate the appropriate dynamics within the team, we must celebrate the impacts we achieve (changes in user behavior, metric improvements, cost reductions, etc.) and not so much the functionalities we make available (which would only be the means). It is also essential that we celebrate the learnings since they allow us to make better decisions and increase future impact.</li></ul></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggSN_dtlajsZ3GF0dqhuWBjAd0X7wrHTTQQ07-JUzk0i9SBxiWqMrWqvUoP7FVrT23E5DE6Nd_6QeiqLoBF7WVEa2Mj8N41nZmPXgcg5jFKsyuzFhtqW9MzyBj4LYxhQJXMIMTFHESJcnyeH9fItB1t8E3a_t9ge9ls86xbXcxqLbPwC2WBQt5/s1405/right_thing-thing_right.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="691" data-original-width="1405" height="314" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggSN_dtlajsZ3GF0dqhuWBjAd0X7wrHTTQQ07-JUzk0i9SBxiWqMrWqvUoP7FVrT23E5DE6Nd_6QeiqLoBF7WVEa2Mj8N41nZmPXgcg5jFKsyuzFhtqW9MzyBj4LYxhQJXMIMTFHESJcnyeH9fItB1t8E3a_t9ge9ls86xbXcxqLbPwC2WBQt5/w640-h314/right_thing-thing_right.png" width="640" /></a></div><br /><div><br /></div><div><br /></div><h2 style="text-align: left;">Conclusion</h2><div>In conclusion, lean product development is a critical component of effective product teams. By prioritizing product discovery&delivery and incorporating it into system architecture and practices, teams can maximize outcomes, minimize waste, and deliver high-impact solutions. It is essential for engineers to embrace a product mindset and actively participate in all aspect of the product development process (discovery, delivery). By doing so, they can contribute to innovation and drive the success of their product teams.</div><div><br /></div><div>If you want to learn more about product discovery&delivery and effective product teams, I recommend reading the following books:</div><div><ul style="text-align: left;"><li><a href="https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339">"Accelerate: The Science of Lean Software and DevOps" by Nicole Forsgren, Jez Humble, and Gene Kim</a></li><li><a href="https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009">"The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen</a></li><li><a href="https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898">"The Lean Startup" by Eric Ries</a></li><li><a href="https://www.amazon.com/Lean-Mindset-Ask-Right-Questions/dp/0321896904">"The Lean Mindset: Ask the Right Questions" by Mary&Tom Poppendieck</a></li><li><a href="https://www.amazon.com/Escaping-Build-Trap-Melissa-Perri/dp/149197379X">"Escaping the Build Trap" by Melissa Perri</a></li><li><a href="https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507">"Inspired: How to Create Tech Products Customers Love" by Marty Cagan</a></li></ul></div><div>Or if you prefer talks, I recommend these ones:</div><div><ul style="text-align: left;"><li><a href="https://www.youtube.com/watch?v=ZSdsjpCcpFw">Competing On The Basis Of Speed by Mary Poppendieck</a> </li><li><a href="https://vimeo.com/163573399">Keynote: Friction by Mary Poppendieck</a> </li><li><a href="https://www.youtube.com/watch?v=GnK_n9Udhhs">Agile Adria 2013 keynote: Make Impacts Not Software by Gojko Adzic</a> </li><li><a href="https://www.youtube.com/watch?v=EoJFWdhv8q0">Beyond Features: rethinking agile software delivery by Dan North</a> </li><li><a href="https://www.youtube.com/watch?v=NGdx-f-aGXs">Creating Value and Flow in Product Development by John Cutler</a> </li></ul></div><div>Remember, product development and continuous delivery go hand in hand. To achieve success, product teams must embrace both and strive for continuous learning and improvement.</div><h2 style="text-align: left;">References and related content</h2><div><ul style="text-align: left;"><li><a href="https://www.svpg.com/empowered-product-teams/">https://www.svpg.com/empowered-product-teams/</a></li><li><a href="https://www.eferro.net/2020/06/technology-at-core-of-product-discovery.html">https://www.eferro.net/2020/06/technology-at-core-of-product-discovery.html</a></li><li><a href="https://www.eferro.net/2022/08/software-development-art-of-postponing.html">https://www.eferro.net/2022/08/software-development-art-of-postponing.html</a></li><li><a href="https://productdeveloper.net/from-software-engineer-to-product-engineer/">https://productdeveloper.net/from-software-engineer-to-product-engineer/</a></li><li><a href="https://productdeveloper.net/iterative-incremental-development/">https://productdeveloper.net/iterative-incremental-development/</a></li><li><a href="https://www.eferro.net/2021/02/basal-cost-of-software.html">https://www.eferro.net/2021/02/basal-cost-of-software.html</a></li><li><a href="https://jpattonassociates.com/dont_know_what_i_want/">https://jpattonassociates.com/dont_know_what_i_want/</a></li></ul></div><div><br /></div><div><br /></div></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-61912555203395381642023-08-09T16:42:00.002+02:002023-08-09T16:42:19.699+02:00Engineering & Product relationship: random notes<p><span style="font-size: x-small;">These notes come from my preparation for a panel on technology and product to which I was invited (<a href="https://lu.ma/tech-sherpas-madrid">https://lu.ma/tech-sherpas-madrid</a>). I am publishing them here in case they contribute or help to initiate some conversation. Of course, the panel was great, and it included responses from <a href="https://www.linkedin.com/in/fontcuberta/">Isaura Fontcuberta</a> and <a href="https://www.linkedin.com/in/rebeca-francisco-najarro/">Rebeca Francisco Najarro</a> that contributed more than my own, but for obvious reasons this post only includes mine since they are the ones I have notes on. The panel was very well conducted by <a href="https://www.linkedin.com/in/pedropabloaparicio">Pedro Pablo Aparicio</a></span></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifbtbmFdTZDKJEhHpBMhQ3iYMf8TRHNgh73mJod6Lo1tEtXJO8UI3mfQUtHBL-refw9LBDwf4pM-79m80BpaLNn4IEiPz5qAPE3fZN2kMsRKf4uqKlWYfG3o-8q65bwKAbWZliBcfrOlAruBWwfwGjyspP5ZRViENNBbV5phBriuPGz6bo77hY/s960/2023-06-tech-sherpa-madrid.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="480" data-original-width="960" height="160" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifbtbmFdTZDKJEhHpBMhQ3iYMf8TRHNgh73mJod6Lo1tEtXJO8UI3mfQUtHBL-refw9LBDwf4pM-79m80BpaLNn4IEiPz5qAPE3fZN2kMsRKf4uqKlWYfG3o-8q65bwKAbWZliBcfrOlAruBWwfwGjyspP5ZRViENNBbV5phBriuPGz6bo77hY/s320/2023-06-tech-sherpa-madrid.png" width="320" /></a></div><br /><span style="font-size: x-small;"><br /></span><p></p><h2>Q&A Notes</h2><p><b>Let's start, should a product company have two Product and Technology Roadmaps, or should it have a single roadmap?</b></p><p>Ideally a single balanced roadmap. The problem is that in my experience this has many implications. Assuming that there are two different reporting lines (something that we should be able to question), there tends to be an imbalance. By instilling product sensitivity within engineering, this imbalance can be mitigated, making engineering attuned to these sensitivities without seeing them as antagonistic. On a small scale, what has worked best for me is that this division does not exist at all. :) If, out of necessity, there are two roadmaps, there must be clear rules for prioritizing (percentages, for example). (See: <a href="https://www.eferro.net/2021/10/it-depends-development-mix-product.html">https://www.eferro.net/2021/10/it-depends-development-mix-product.html</a>)</p><p><b><br /></b></p><p><b>Continuing with the topic, taking advantage of the fact that we are talking about RoadMap, who is responsible in the case that there is 1 or 2 roadmaps….</b></p><p>If two reporting lines exist, it becomes a matter of negotiation, although I question the necessity for dual lines in all situations. The final responsibility can vary depending on several factors such as the nature of the product (be it business digitalization, information systems, or deep tech), the business domain's complexity, or our strategic approach. More often than not, Product assumes the final responsibility. Regardless, my fundamental belief is that product development is a cooperative team endeavor. Thus, if two lines exist, the process mandates not just continuous negotiation but, even more importantly, continuous collaboration.</p><p><br /></p><p><b>Do these product minded engineers exist? Is it a creation, what would be its definition?</b></p><p>They exist, and I know quite a few. I would also consider myself in that group. Actually, seeing software as a means to achieve an impact (product) is one of my fundamental premises of this profession. Obviously you need to recruit with this mindset in mind, fostering and developing this orientation among your team members. My experience at Alea Solutions and The Motion has been like this, and then at Nextail and ClarityAI. I strive to ensure that my teams adopt this mentality, and my hiring practices reflect it. (See: <a href="https://productdeveloper.net/from-software-engineer-to-product-engineer/">https://productdeveloper.net/from-software-engineer-to-product-engineer/</a> <a href="https://svpg.com/empowered-product-teams/">https://svpg.com/empowered-product-teams/</a> )</p><p><br /></p><p><b>Do all engineers have to have this predisposition or what would be the percentage within the team or squad to carry it out?</b></p><p>At least the senior people on the team. In any case, I think this mindset can be generated and trained. In some cases where the product is very technical or deep tech, perhaps there wouldn't be as much difference between people who have this predisposition and people who don't.</p><p><br /></p><p><b>Do you think it is good that there are two people as leaders of product and technology? Does it depend on the type of product or company? </b></p><p>I believe that it's not necessary and that it's a problem that has arisen due to the speed of innovation and the immense amount of technologies and the cognitive load that this generates. </p><p>Nonetheless, I firmly believe we need to actively address this issue. It is essential to guide engineers towards understanding that their work's ultimate goal is creating impact, while also helping Product people to grasp the necessity of sustainable engineering processes and practices. From my perspective, the solution is intimately linked with lean methodologies, specifically Lean Software Development and Lean Product Development.</p><p><br /></p><p><b>The alignment between Product Manager (PM) and Tech Lead (TL), what is in your experience the best way to achieve this alignment?</b></p><p>Promote cooperation understanding that the result and impact is always at the team level. In that context, the PM, has to learn about sustainable software development and the TL must learn about product/impact and how to work with customers. Both must also learn techniques to maximize impact and develop product in very small steps, with continuous feedback, postponing decisions until the last responsible moment, minimizing as much as possible the Basal Cost of the solution. (See: <a href="https://www.eferro.net/2021/02/basal-cost-of-software.html">https://www.eferro.net/2021/02/basal-cost-of-software.html</a> )</p><p><br /></p><h2 style="text-align: left;">Closing / Conclusions</h2><p><b>As a closing, can you give your 2-3 tips, based on your experience, on how to have a great relationship between Product and Technology?</b></p><p></p><ol style="text-align: left;"><li>1 Hire/grow product (minded) engineers. It's easier to learn about product/business as a developer than the other way around (plus it's necessary).</li><li>2 Many of the tensions are alleviated by using the same language (centered on business), defining product boundaries, clear acceptance criteria and clearly defining what is a prototype, an MVP, and a normal product (so that it's defined how to make each one).</li><li>3 If performance is incentivized and evaluated at the team level with common objectives, I think it's much easier to align. Of course this implies that the objectives include sustainability and the ability to continue the evolution of the system."</li></ol><p></p><div><br /></div><div><br /></div><h2 style="text-align: left;">References:</h2><div><ul style="text-align: left;"><li><a href="https://www.eferro.net/2021/10/it-depends-development-mix-product.html">https://www.eferro.net/2021/10/it-depends-development-mix-product.html</a></li><li><a href="https://productdeveloper.net/from-software-engineer-to-product-engineer/">https://productdeveloper.net/from-software-engineer-to-product-engineer/</a></li><li><a href="https://svpg.com/empowered-product-teams/">https://svpg.com/empowered-product-teams/</a> </li><li><a href="https://www.eferro.net/2021/02/basal-cost-of-software.html">https://www.eferro.net/2021/02/basal-cost-of-software.html</a></li></ul></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-21260607576075503822023-06-18T09:02:00.000+02:002023-06-18T09:02:31.247+02:00Good talks/podcasts (Jun 2023 I)<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-8xBxNQfTeRFjOJHRnLc_CaZCfDWKIPOikZ4OsZYh2NNJEmHKkIaBGCg79b4sjrTcCzHBL8KR8aaUYH4kVvaLk2JQsYmwWv52fYbVjWZD6Khtgfkdwz7oDAIQrpNgj1QoY9WbgfEKIziKqkxtDosUfFIwU-6AXPqTPdt8VB9TdqHRhcWaGQ/s1444/school_class_covid.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="586" data-original-width="1444" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-8xBxNQfTeRFjOJHRnLc_CaZCfDWKIPOikZ4OsZYh2NNJEmHKkIaBGCg79b4sjrTcCzHBL8KR8aaUYH4kVvaLk2JQsYmwWv52fYbVjWZD6Khtgfkdwz7oDAIQrpNgj1QoY9WbgfEKIziKqkxtDosUfFIwU-6AXPqTPdt8VB9TdqHRhcWaGQ/s320/school_class_covid.png" width="320" /></a></div><br /> <p></p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=DyM4NtlIL44">Sabotaging a Transformation</a>
<b>(Fred George)</b>
<b>[Agile, Culture, Inspirational, Transformation]</b>
<b>[Duration: 0:42:00]</b>
Real experiences on Agile transformations: common obstacles and strategies to overcome them. Specifically, it addresses: executive unawareness, lack of engagement, power shifts, and blame-oriented cultures.
</li>
<li>
<a href="https://smallbatches.fm/84">Software delivery in small batches: Dr. Deming</a>
<b>(Adam Hawkins)</b>
<b>[Devops, Lean, Lean Software Development]</b>
<b>[Duration: 0:14:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
This episode highlights the significant impact of Dr. W. Edwards Deming on lean manufacturing, Total Quality Control (TQC), and the subsequent development of DevOps in software delivery. Deming's focus on holistic thinking, continuous improvement, and understanding the system laid the groundwork for lean principles, which later influenced the emergence of DevOps, revolutionizing software development and operations.
</li>
<li>
<a href="https://www.youtube.com/watch?v=XMyt5S8limQ">Improving Software Flow</a>
<b>(Randy Shoup)</b>
<b>[Devops, Flow, Inspirational, Lean, Lean Software Development, Technical leadership, leadership]</b>
<b>[Duration: 0:50:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
In this session, Randy explains how they improve the overall flow and the engineering capacity following the ideas in the Unicorn Project (Locality and Simplicity, Focus, Flow, and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus). It is an excellent talk about generating/improving an engineering culture following lean principles.
</li>
<li>
<a href="https://www.youtube.com/watch?v=9r9WDzzTcr0">AWS Community Day Nordics 2023 - The Tao of Event-Driven Architectures</a>
<b>(Luc van Donkersgoed)</b>
<b>[Architecture, Architecture patterns, Serverless, Technology Strategy]</b>
<b>[Duration: 0:30:00]</b>
In this talk Luc presents 10 simple rules to organize and standardize event-driven systems, which helps build future-proof implementations.
</li>
</ul>
<b>Reminder:</b> All of these talks are interesting, even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-33944817155387385162023-05-07T19:09:00.000+02:002023-05-07T19:09:02.343+02:00Good talks/podcasts (May 2023 I)<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-8xBxNQfTeRFjOJHRnLc_CaZCfDWKIPOikZ4OsZYh2NNJEmHKkIaBGCg79b4sjrTcCzHBL8KR8aaUYH4kVvaLk2JQsYmwWv52fYbVjWZD6Khtgfkdwz7oDAIQrpNgj1QoY9WbgfEKIziKqkxtDosUfFIwU-6AXPqTPdt8VB9TdqHRhcWaGQ/s1444/school_class_covid.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="586" data-original-width="1444" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-8xBxNQfTeRFjOJHRnLc_CaZCfDWKIPOikZ4OsZYh2NNJEmHKkIaBGCg79b4sjrTcCzHBL8KR8aaUYH4kVvaLk2JQsYmwWv52fYbVjWZD6Khtgfkdwz7oDAIQrpNgj1QoY9WbgfEKIziKqkxtDosUfFIwU-6AXPqTPdt8VB9TdqHRhcWaGQ/s320/school_class_covid.png" width="320" /></a></div><br /> <p></p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=Sqa8Zo2XWc4">Artificial Intelligence: Last Week Tonight with John Oliver</a>
<b>(John Oliver)</b>
<b>[AI]</b>
<b>[Duration: 0:27:00]</b>
Funny report on the state of artificial intelligence. Presentation for all audiences. Not technical.
</li>
<li>
<a href="https://www.youtube.com/watch?v=w9YhmMPLQ4U">Prioritizing Technical Debt as If Time & Money Matters. Goto 2022</a>
<b>(Adam Tornhill)</b>
<b>[Engineering productivity, Technology Strategy]</b>
<b>[Duration: 0:28:00]</b>
Adam presents an interesting approach for classifying and tackling technical debt based on analyzing code changes over time, by authors and files, in order to identify hotspots worth investing in.
</li>
<li>
<a href="https://www.youtube.com/watch?v=7SNbDWob6cI">The Difference Between Continuous Delivery & Continuous Deployment</a>
<b>(Dave Farley)</b>
<b>[Continuous Delivery, Technical Practices, Technology Strategy]</b>
<b>[Duration: 0:18:00]</b>
In this episode Dave describes the differences between Continuous Delivery and Continuous Deployment: what each one gives you and when Continuous Deployment may not always be the correct answer.
</li>
<li>
<a href="https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase">The wet codebase</a>
<b>(Dan Abramov)</b>
<b>[Software Design, Technical Practices]</b>
<b>[Duration: 0:25:00]</b>
Interesting talk about software design, design principles, and how it's worth understanding them in their context to apply them correctly. It reminded me of this post I wrote about the DRY principle https://www.eferro.net/2017/02/applying-dry-principle.html
</li>
<li>
<a href="https://www.thisamericanlife.org/561/nummi-2015">NUMMI (2015)</a>
<b>(Frank Langfitt)</b>
<b>[Lean, Lean Manufacturing]</b>
<b>[Duration: 1:04:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
The interesting history of the NUMMI plant and the joint venture between GM & Toyota.
A good story to understand some of the lean principles. There is a previous version of the podcast with other interviews at https://www.thisamericanlife.org/403/nummi-2010
</li>
<li>
<a href="https://www.youtube.com/watch?v=lHoOUylvfxQ">Many More Much Smaller Steps with GeePaw Hill</a>
<b>(GeePaw Hill, Chris Lucian, Austin Chadwick)</b>
<b>[Evolutionary Design, Lean Software Development, Software Design, Technical Practices, XP]</b>
<b>[Duration: 0:39:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Good conversation about GeePaw Hill's software development approach based on taking continuous small safe steps (Many More Much Smaller Steps).
</li>
</ul>
<b>Reminder</b>, All these talks are interesting even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-38294349735867824372023-05-01T21:16:00.001+02:002023-05-01T21:16:54.802+02:00Lean Coffee: Defer Commitment / Postponer decisiones
<p>El pasado lunes 24/04/2023 tuve el placer de poder colaborar en un Lean Coffee sobre uno de los principios Lean que más me interesan y que creo que menos gente pone en práctica: Defer Commitment.</p><p>Gracias a todos los participantes creo que quedo una sesión muy interesante y que espero que tenga continuidad en alguna otra sesión futura.</p>
<p>Gracias a todas las comunidades de Software Crafters que quisieron colaborar con la iniciativa:</p>
<ul>
<li><a href="https://twitter.com/bcnswcraft">Software Crafters Barcelona</a></li>
<li><a href="https://twitter.com/madswcraft">SW Crafters Madrid</a></li>
<li><a href="https://twitter.com/murciaswcraft">Murcia Software Craftersz</a></li>
<li><a href="https://twitter.com/MalagaSwCraft">Software Crafters Málaga</a></li>
</ul>
<p>Aquí tenéis el vídeo:</p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/OmQ8zoQvn8I" title="YouTube video player" width="560"></iframe>
<p>
Aquí teneís un hilo con algunas de las preguntas y respuestas que se dejaron en el panel:
</p>
<blockquote class="twitter-tweet"><p dir="ltr" lang="ca">Si el Lunes os perdisteis el evento de Lean Software Development - Defer Commitment os dejamos aquí la grabación del evento, subida por la <a href="https://twitter.com/MalagaSwCraft?ref_src=twsrc%5Etfw">@MalagaSwCraft</a><a href="https://t.co/DJ27PYembV">https://t.co/DJ27PYembV</a></p>— Murcia Software Crafters (@murciaswcraft) <a href="https://twitter.com/murciaswcraft/status/1651439907728924672?ref_src=twsrc%5Etfw">April 27, 2023</a></blockquote> <script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>
<h2>Referencias y Lecturas relacionadas</h2>
<ul>
<li><a href="https://www.amazon.com/exec/obidos/ASIN/0321150783/poppendieckco-20">Lean Software Development: An Agile Toolkit</a></li>
<li><a href="https://www.eferro.net/2022/08/software-development-art-of-postponing.html">Lean Software development: The art of postponing decisions</a></li>
<li><a href="https://twitter.com/GeePawHill/status/1473025726282665986">Many More Much Smaller Steps (MMMSS)</a> <a href="https://twitter.com/GeePawHill">@GeePawHill</a></li>
<li><a href="https://www.geepawhill.org/2021/09/29/many-more-much-smaller-steps-first-sketch/">Many More Much Smaller Steps – First Sketch</a> <a href="https://twitter.com/GeePawHill">@GeePawHill</a></li>
</ul>
eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-25500449821419306082023-04-23T20:40:00.004+02:002023-04-23T20:40:55.024+02:00Good talks/podcasts (Apr 2023 I)<p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhY8cmB3b13DKjkm4dw_g-7Zby3T5QirEgL7s8lkA2YjRIb077lpgL-UhDLg97iYTRclDykKNbgL-3sTKOeXHaWuALgZWVe9mQaukEyi7hrkcT-kDISoglTSmZXK9gtM1jWMcFigIDz-5SE1fwq7o2KYmwuFCgvwFpOX5DJHQQp8xtK9YJDA/s1370/undraw_youtube_tutorial_2gn3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="992" data-original-width="1370" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhY8cmB3b13DKjkm4dw_g-7Zby3T5QirEgL7s8lkA2YjRIb077lpgL-UhDLg97iYTRclDykKNbgL-3sTKOeXHaWuALgZWVe9mQaukEyi7hrkcT-kDISoglTSmZXK9gtM1jWMcFigIDz-5SE1fwq7o2KYmwuFCgvwFpOX5DJHQQp8xtK9YJDA/s320/undraw_youtube_tutorial_2gn3.png" width="320" /></a></div><br /><p></p>
These are the best podcasts/talks I've seen/listened to recently:
<ul>
<li>
<a href="https://www.youtube.com/watch?v=guycIP56YeY">Kent Beck On The FIRST Testing Frameworks, TDD, Waterfall & MORE | The Engineering Room Ep. 16</a>
<b>(Kent Beck, Dave Farley)</b>
<b>[Agile, Inspirational, XP]</b>
<b>[Duration: 1:07:00]</b>
In this episode of the Engineering Room, Dave Farley and Kent Beck have a wide-ranging discussion about the return of waterfall development in software, TDD, Software Design and lots of other things along the way.
</li>
<li>
<a href="https://www.youtube.com/watch?v=mcnxxdzC2fY">Master Class with Marty Cagan</a>
<b>(Marty Cagan)</b>
<b>[Inspirational, Product, Product Discovery, Product Leadership, Product Team, leadership]</b>
<b>[Duration: 1:21:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
A great presentation on skilled product teams and leading product organizations. The questions at the end are also very interesting.
</li>
<li>
<a href="https://www.youtube.com/watch?v=3MxAUurD9gU">High WIP, multi-tasking, etc.</a>
<b>(John Cutler)</b>
<b>[Lean, WIP]</b>
<b>[Duration: 8:37:00]</b>
<b>(⭐⭐⭐⭐⭐)</b>
Great explanation about the harmful impact of having high work in progress.
</li>
<li>
<a href="https://www.youtube.com/watch?v=v6hP2MXoVrI">Don't Mock 3rd Party Code</a>
<b>(Dave Farley)</b>
<b>[Software Design, Technical Practices, testing]</b>
<b>[Duration: 19:55:00]</b>
In this episode Dave explains the dangers of mocking third party code, whose evolution and change we have no control over.
</li>
<li>
<a href="https://pulling-the-strings.simplecast.com/episodes/the-future-of-platform-engineering">The Future of Platform Engineering</a>
<b>(Kaspar von Grünberg, Ben Ford, Nigel Kersten, Fatih Degirmenci, Ronan Keenan)</b>
<b>[Devops, Platform, Platform as a product, Platform engineering]</b>
<b>[Duration: 0:37:00]</b>
Interesting discussion about Platform Engineering.
</li>
<li>
<a href="https://www.youtube.com/watch?v=rkJNflZ9S5E">Software Craftsmanship al descubierto con Mashooq Badar</a>
<b>(Mashooq Badar)</b>
<b>[Craftmanship, Inspirational, XP]</b>
<b>[Duration: 0:31:00]</b>
Interesting interview with Mashooq Badar, one of the founders of the craftmanship software movement in London.
</li>
</ul>
<b>Reminder</b>, All these talks are interesting even just listening to them.<br />
<br />
<b>Related:</b><br />
<ul>
<li><a href="http://www.eferro.net/p/recommended-talks-and-podcasts.html">Recommended Talk/Podcast Database</a></li>
<li><a href="https://www.eferro.net/search/label/recommended%20resources">Recommended resources tag</a></li>
</ul>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-50489908442073548052023-04-04T16:15:00.004+02:002023-04-07T10:00:30.045+02:00Thin infrastructure wrappers<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhf8wBIIQtZZC7c8l87EemKCtjmIOMEjxSRL1nEnaY6Jcfl9YxnUsbFfsaVp-vEoaezFoVnYoQ4FPFHI97F0xvbEx2JszM4Rw1fZ5Y3Cnz05DTfNMBCRU7XapIIgQK4o_ecHl6omWpmw7tog2YqYQnmRMrx_c7FjFWpzeyV0A_otmB8vX5UYw/s1584/infra-wrapper4.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="687" data-original-width="1584" height="174" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhf8wBIIQtZZC7c8l87EemKCtjmIOMEjxSRL1nEnaY6Jcfl9YxnUsbFfsaVp-vEoaezFoVnYoQ4FPFHI97F0xvbEx2JszM4Rw1fZ5Y3Cnz05DTfNMBCRU7XapIIgQK4o_ecHl6omWpmw7tog2YqYQnmRMrx_c7FjFWpzeyV0A_otmB8vX5UYw/w400-h174/infra-wrapper4.png" width="400" /></a></div><br /><p><br /></p><p>Normally, when using architectures that separate infrastructure code from the rest of the application (hexagonal architecture, clean architecture), it is advantageous to create Thin Infrastructure Wrappers. These wrappers allow us to control (and limit) how we use that infrastructure and decouple us from it.</p><p>I've been using this approach for over a decade, and it has always worked very well for me. <b>Also, the small cost of creating the wrapper has always been worth it.</b></p><p><br /></p><p>Moreover, these wrappers allow us to use them as boundaries with the infrastructure and <b>avoid mocking third-party libraries</b>, which, although sometimes might seem like a good idea, I can say from experience that is a bad decision that couples us with the concrete implementation and makes it harder to apply TDD with the rest of the code.</p><p>When we decouple the infrastructure services using a thin wrapper, we can define some Integration tests to validate the implementation and mock/fake the wrapper to implement the rest of the application (instead of mocking the 3ºParty SDK/driver).</p><p>Advantages of this approach:</p><p></p><ul style="text-align: left;"><li>Minimal API surface (minimal features of the infrastructure used) </li><li>Minimal number of slow integration tests</li><li>Minimized technology-based code spreading through the code base</li><li>It allows us to create code that is more tailored to the business language, separating us from purely technical concepts</li><li>Easy to validate new SDK/infrastructure changes</li><li>Easy to upgrade to new SDK/infrastructure version (including fast security patching)</li><li>Enable TDD flow even for code that uses/integrate infrastructure services</li><li>Less tendency to vendor lock-in (as we reduce the coupling with the infrastructure to the minimum)</li></ul><p></p><p></p><p></p><p>Sometimes if we need to use most of the concrete infrastructure functionalities and characteristics (performance, scalability, etc), the thin infrastructure wrapper is not so thin, and we need a different approach. But in most cases, this approach has more advantages than disadvantages.</p><p><br /></p><h3 style="text-align: left;">Example / Redis Cache</h3><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9K2aJ1Ptr-UEx68sGB5K82sP3UmDv6e1Od51HEI2Uhgj7ZcsP0eAv6QYJNuIp-7n6s6uL6coxT6d7FdqeKm6XmRZ2DzlrDROhQAOU54au80ijbbOlenYuBxR3aqLbuh9sxmmYN17CcyAeT6qwcYENECQgt9tCwtOkBiOzsGqC8HAG3aRYXQ/s1720/infra-wrapper5.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="840" data-original-width="1720" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9K2aJ1Ptr-UEx68sGB5K82sP3UmDv6e1Od51HEI2Uhgj7ZcsP0eAv6QYJNuIp-7n6s6uL6coxT6d7FdqeKm6XmRZ2DzlrDROhQAOU54au80ijbbOlenYuBxR3aqLbuh9sxmmYN17CcyAeT6qwcYENECQgt9tCwtOkBiOzsGqC8HAG3aRYXQ/w640-h312/infra-wrapper5.png" width="640" /></a></div><br /><p>Imagine that we need to implement a Cache in our system. We analyze different options and decided that a multi-node Redis cluster can do a good job. As we only need a cache and we use lean software development, we try to satisfy only the current needs (Yagni, defer commitment, simplicity, etc). This means that despite Redis having many use cases and functionalities, we limit its use to the minimum number of functionalities necessary to implement the cache. In this case, it would suffice to have: set_key_with_ttl, get_key, remove_key.</p><p>So the RedisWrapper (Thin Infrastructure Wrapper) can be defined as:</p><p><span style="font-family: courier;">RedisWrapper</span></p><p></p><ul style="text-align: left;"><li><span style="font-family: courier;">set_key_with_ttl(key, value, ttl)</span></li><li><span style="font-family: courier;">get_key(key): value</span></li><li><span style="font-family: courier;">remove_key(key)</span></li></ul><p></p><p><br /></p><p>This small piece can be validated easily with a few small integration tests:</p><p></p><ul style="text-align: left;"><li><span style="font-family: courier;">it_should_return_the_previously_stored_value</span></li><li><span style="font-family: courier;">a _key_should_expire_when_its_ttl_is_over</span></li><li><span style="font-family: courier;">it_does_not_return_a_key_not_previously_stored</span></li><li><span style="font-family: courier;">it_does_not_return_a_removed_key</span></li><li><span style="font-family: courier;">…</span></li></ul><p></p><p><br /></p><p>Having this Thin Wrapper, we can develop with TDD a Cache class using only fast unit tests that validate with test doubles the usage of the RedisWrapper. The rest of our system doesn’t require interacting with Redis directly and will only use the Cache class. </p><p><br /></p><p>The important thing, in any case, is that although Redis provides us with many types of data (hashmaps, sets, counters, etc...) and allows us to implement many patterns (distributed locks, leader boards, bloom filters, object persistence, cache), we focus only on what we need now, thus minimizing the surface area to cover. This allows us to only worry about whether the use case we are using still works when a new version exists, which we can quickly validate with our wrapper integration tests.</p><p>In some cases, if the wrapper interface makes it easy to implement the use cases we need, we can include the implementation in the wrapper itself and create only one abstraction instead of two. In our example, this would mean that if implementing the cache using our RedisWrapper is straightforward, we could just use one abstraction and implement a RedisCache class instead of two (RedisWrapper and Cache). Of course, this only makes sense when there is little logic to implement.</p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQf5WvpoN3F3UKb00a0yQMbDlmB04YbCVP_kB3a6Pcv6sFdVUpYgTuQ5nvf9FJMKnk8jz1edoduLRgfAcmEwn3xHExnYKy8rDCqIHTonCQ0svJtlCqkoU0tvnls-tUpVK0WXZqWLFH3JFWyJFASh08oZKw2lOW6fJsKSKZYJLADOEap53dpA/s1584/infra-wrapper3.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="544" data-original-width="1584" height="138" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQf5WvpoN3F3UKb00a0yQMbDlmB04YbCVP_kB3a6Pcv6sFdVUpYgTuQ5nvf9FJMKnk8jz1edoduLRgfAcmEwn3xHExnYKy8rDCqIHTonCQ0svJtlCqkoU0tvnls-tUpVK0WXZqWLFH3JFWyJFASh08oZKw2lOW6fJsKSKZYJLADOEap53dpA/w400-h138/infra-wrapper3.png" width="400" /></a></div><br /><h2 style="text-align: left;">Example / RabbitMQ</h2><p>If we have to implement queue-based communications, we can actually divide the use case into two parts: the publisher and the subscriber.</p><p>If the RabbitMQ SDK makes it very easy to implement both the publisher and the subscriber use cases, a good option is to create only one class for each use case that includes the wrapper and the minimum logic to create the publisher and the subscriber.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOeLnbv9gtVTszTk1JUzdGCUKpHcyHpo0EHmN438kiiEumYBKiFtIi43UBhrmW5FuuUTYauJq3r7YtUPbl8uGXaRfpm0_TrZU1rl7DK-A5M1FB3YDuB6JUK7jJR1bhCEpD47pVa9VSkNQZB0go1X2v7lHijgsm4uNMRQMUvHLpcSrRi6AulA/s1856/infra-wrapper9.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1416" data-original-width="1856" height="488" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOeLnbv9gtVTszTk1JUzdGCUKpHcyHpo0EHmN438kiiEumYBKiFtIi43UBhrmW5FuuUTYauJq3r7YtUPbl8uGXaRfpm0_TrZU1rl7DK-A5M1FB3YDuB6JUK7jJR1bhCEpD47pVa9VSkNQZB0go1X2v7lHijgsm4uNMRQMUvHLpcSrRi6AulA/w640-h488/infra-wrapper9.png" width="640" /></a></div><br /><p>In that case, the interface of the classes could look like this:</p><p><span style="font-family: courier;">QueuePublisher</span></p><p></p><ul style="text-align: left;"><li><span style="font-family: courier;">publish_message(topic, message)</span></li></ul><p></p><p><span style="font-family: courier;"><br /></span></p><p><span style="font-family: courier;">QueueSubscriber</span></p><p></p><ul style="text-align: left;"><li><span style="font-family: courier;">subscribe(topic, message_processing_function)</span></li></ul><p></p><p><br /></p><h2 style="text-align: left;">Example / AWS boto</h2><p>Upon entering TheMotion, the initial team had created the foundations of what would later become the product. It consisted of a pipeline of different applications that generated videos from templates, photos, and other dynamic elements. The system ran on AWS, and the different applications communicated using queues (AWS SQS) and stored images and rendered video parts in AWS S3.</p><p>Unfortunately, the initial team did not have the habit of wrapping third-party SDKs, so all applications were filled with calls to boto, the AWS SDK for Python, scattered throughout the code. The result of this approach was:</p><p></p><ul style="text-align: left;"><li>Integration tests that only covered some cases (since many similar cases were scattered throughout the code).</li><li>Unit tests that were very difficult to understand. They used Moto (https://docs.getmoto.org/en/latest/) as a library to mock the AWS SDK (boto). The Setup phase of those tests was infernal since it required many low-level calls.</li><li>They only covered some cases due to the cost of developing these tests. The same problem that with the integration tests.</li><li>We had many errors and debugging problems because it was so difficult to control how each developer used the AWS services (different flags, configurations, etc.) was so difficult. Using boto directly gives too many options for inexperienced AWS developers.</li><li>Updating boto versions was a titanic task, so the library's version was outdated (and was likely insecure).</li></ul><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikPLT0SBkFQ5-TMF5ik7_ZR5vgdFqc8hbuCA3XCyonqdaF3Gre3dsIxgZlNOArYoz3gHJzXUHUHJxWHsBl4m9Hj9EVQbyVOvmJ8HODYSxNpR7rd2v5yzSiD7H5SyBPu44pSIgZH_pd4CMh4gP-JX613sZ_6-mtMks93ZhjDBS27VfD4-8IZQ/s1648/infra-wrapper10.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="858" data-original-width="1648" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikPLT0SBkFQ5-TMF5ik7_ZR5vgdFqc8hbuCA3XCyonqdaF3Gre3dsIxgZlNOArYoz3gHJzXUHUHJxWHsBl4m9Hj9EVQbyVOvmJ8HODYSxNpR7rd2v5yzSiD7H5SyBPu44pSIgZH_pd4CMh4gP-JX613sZ_6-mtMks93ZhjDBS27VfD4-8IZQ/w400-h209/infra-wrapper10.png" width="400" /></a></div><br /><div><br /></div><div><br /></div><p></p><p>In summary, it was a technical debt hell that prevented us from progressing with good testing practices and generated a lot of frustration in our day-to-day work.</p><p>With this starting point and identifying the lack of infrastructure wrappers as one of the problems of the initial codebase, we carried out a systematic and conscious process to solve the problem.</p><p></p><ol style="text-align: left;"><li>We identified the uses of boto throughout the application and defined basic use cases (which covered 80% of the cases).</li><li>We implemented several wrappers that practically maintained the AWS boto API as it was used in the applications. That is, we created wrappers for publishing messages to SQS and for saving and retrieving objects/files with AWS S3. These initial wrappers were very similar to the boto API but encapsulated sequences of calls that we always repeated (connecting, getting the client, etc.).</li><li>With these wrappers and by extending the wrapper API as needed, we gradually replaced direct use of boto with the wrappers. At the same time, we modified and simplified the tests.</li><li>During the substitution and adaptation process, we identified every subtle difference in the use of the AWS API, analyzing whether the difference was necessary or simply the result of chance. If it was necessary, we adapted the API of our wrapper. Otherwise, we simply removed and simplified it.</li><li>We removed all the old code when all AWS uses pointed to the new wrappers.</li><li>As a final step, we simplified the API of the wrappers by adapting them to their use, rather than to how the AWS API is designed.</li></ol><p></p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoULJwaU4NgYd3V90S0w1yq1--htZ1hBJRD3rnlNeq2nQ7F_vS_cLUZYeiatlysIbOujX93_ufzZI-WaTgO18sGYfIvH3rZGqIpmZVLSGqq4tsueLq5TmUBMyvaAou1y_8OKyDa7rdjsOwxXu2PGaGERgwnX0OUOsFeWCerFDxTpocPvOpOQ/s1524/infra-wrapper1.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="792" data-original-width="1524" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoULJwaU4NgYd3V90S0w1yq1--htZ1hBJRD3rnlNeq2nQ7F_vS_cLUZYeiatlysIbOujX93_ufzZI-WaTgO18sGYfIvH3rZGqIpmZVLSGqq4tsueLq5TmUBMyvaAou1y_8OKyDa7rdjsOwxXu2PGaGERgwnX0OUOsFeWCerFDxTpocPvOpOQ/w400-h208/infra-wrapper1.png" width="400" /></a></div><p>Certainly, this process, although costly, was fundamental to accelerate the subsequent development of the product and to introduce the practices that, as an XP team, allowed us to maintain sustained speed (Continuous Integration, TDD, TBD, etc.).</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEji4F5eEVKqEXQdBjugeKylWx3s8vKf0c0942-IZZpeHzli6uiT0aKOTzTTW8MfrsUW3x70nH8LUrUyJmjkFXjeWJTc1zEmKTVrjatvH4qO8y2RuRdiZbv8gwTio8lOZ1xr5b6kpcRjWWTpGP7RndwSLAw2m7p0FhQpt1-XDFIK8UCsK5F33w" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="235" data-original-width="918" height="164" src="https://blogger.googleusercontent.com/img/a/AVvXsEji4F5eEVKqEXQdBjugeKylWx3s8vKf0c0942-IZZpeHzli6uiT0aKOTzTTW8MfrsUW3x70nH8LUrUyJmjkFXjeWJTc1zEmKTVrjatvH4qO8y2RuRdiZbv8gwTio8lOZ1xr5b6kpcRjWWTpGP7RndwSLAw2m7p0FhQpt1-XDFIK8UCsK5F33w=w640-h164" width="640" /></a></div><p></p><h2 style="text-align: left;"><span style="font-weight: normal;">Conclusions</span></h2><p>SDKs for infrastructure services usually have the following characteristics:</p><p></p><ul style="text-align: left;"><li>They cover all functionalities and use cases of the service/infrastructure.</li><li>They are designed for general use.</li><li>Due to the previous reasons, they have an extensive API (a huge potential coupling surface).</li></ul><p></p><p>On the other hand, in our applications, we need to define what we want from the service and infrastructure very well, minimizing the API to use as much as possible. This way of working allows us to:</p><p></p><ul style="text-align: left;"><li>Minimize coupling</li><li>Make more reversible the decision of using this concrete infrastructure</li><li>Facilitate maintenance (version updates, configuration changes, etc.).</li></ul><p></p><p>Additionally, as professionals (because we are professionals, aren’t we?), we need to facilitate application testing. :)</p><p>In this context, a Thin Wrapper that covers only what we use, is small, and can be easily mocked is a fundamental piece to help us have a decoupled infrastructure.</p><p>In summary, this way of working:</p><p></p><ul style="text-align: left;"><li>Allows us to have tight control over which functionalities and API of an infrastructure service we use.</li><li>Allows for easy and secure updating and changing of that service or driver/SDK version (with the support of integration tests).</li><li>Allows for development using fast unit tests that mock the wrapper we have developed.</li></ul><p></p><p>If we don't create these kinds of wrappers, we may encounter an issue where the use of the infrastructure service API spreads across the application. This can result in a loss of control over the specific functionalities that we are using, and eventually make it difficult to implement any changes to the infrastructure or SDK/driver, including version upgrades, which can become an extremely challenging process.</p><p>Another problem that arises when we don't develop these wrappers is that we create many complicated unit tests that mock or, worse, do monkey patching of many SDK/driver methods.</p><p>In summary, my preferred option is to create a Thin Wrapper to narrow down the parts of the SDK we need and abstract the basic interactions. Then, we would have another class oriented towards business with the necessary abstractions (publishing a message, storing an object, etc.).</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-FMW8RcZa_6okmeIHqFtB7sMirlGeJ489ENZOuDyF1svq57V9PQmPIKwFX9Z4wRl4bYyYZetkiI7PXRJVQI50SuhqyYUEvc34ebCk9RGnt77u0IAd4VVkNgpzLE2ICX5nvm5x0hcMHpXXnE8nkWL_e4Ej8OgJhrIBtbOlFU1a8GREkTPrJQ/s1602/infra-wrapper7.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1155" data-original-width="1602" height="289" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-FMW8RcZa_6okmeIHqFtB7sMirlGeJ489ENZOuDyF1svq57V9PQmPIKwFX9Z4wRl4bYyYZetkiI7PXRJVQI50SuhqyYUEvc34ebCk9RGnt77u0IAd4VVkNgpzLE2ICX5nvm5x0hcMHpXXnE8nkWL_e4Ej8OgJhrIBtbOlFU1a8GREkTPrJQ/w400-h289/infra-wrapper7.png" width="400" /></a></div><br /><p><br /></p><p>As an alternative option, and only if the business need can be implemented with very little logic, we could potentially combine the Thin Wrapper with the business abstraction. However, this should only be done in those cases and assuming there are no other abstractions on that part of the infrastructure.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMbPJxWT496SwsXFt961toPkBKnuK7pvOce8vyiki7wBIQGPAxNVuFrkUFgnCkja14mNq2oQX5_bZKikivJ6-43xSrXnHdEZARRQn4H6pEjWdCcUtAJigsTvefC998bPGe32I8i1fqss682axsPo8C6hG6X1pbq2fB9Czh5J_VkoNR21ZJ9w/s1629/infra-wrapper8.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1155" data-original-width="1629" height="284" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMbPJxWT496SwsXFt961toPkBKnuK7pvOce8vyiki7wBIQGPAxNVuFrkUFgnCkja14mNq2oQX5_bZKikivJ6-43xSrXnHdEZARRQn4H6pEjWdCcUtAJigsTvefC998bPGe32I8i1fqss682axsPo8C6hG6X1pbq2fB9Czh5J_VkoNR21ZJ9w/w400-h284/infra-wrapper8.png" width="400" /></a></div><br /><p><br /></p><p>To ensure adaptability to changes, it is essential to minimize the surface area of the SDK used, keep it under control, and decouple it as much as possible. It's important to note that we have no control over changes to the SDK, as these are determined by third-party entities such as vendors, cloud providers, and communities.</p><h2 style="text-align: left;">Antipatterns</h2><p>When using this approach, one must be very careful not to fall into some of the common pitfalls:</p><p></p><ul style="text-align: left;"><li>Overcomplicating the abstraction</li><li>Allowing complex types or other concepts from the SDK to escape the created abstraction (<a href="https://en.wikipedia.org/wiki/Leaky_abstraction">Leaky abstraction</a>)</li><li>Ending up exposing the entire SDK API "just in case"</li></ul><p></p><div><br /></div><h1 style="text-align: left;"><span style="font-weight: normal;">References and notes:</span></h1><p>In the article we talk about mocks as a generic term, but to clarify, depending on the needs of the test, we should use different types of test doubles (stubs, spies, fakes, mocks, etc.). More info <a href="https://martinfowler.com/bliki/TestDouble.html">https://martinfowler.com/bliki/TestDouble.html</a> and <a href="http://xunitpatterns.com/Test%20Double.html">http://xunitpatterns.com/Test%20Double.html</a></p><p><br /></p><p>References:</p><p></p><ul style="text-align: left;"><li><a href="https://www.youtube.com/watch?v=v6hP2MXoVrI">Don't Mock 3rd Party Code</a> </li><li><a href="https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam">Integrated Tests Are A Scam</a></li><li><a href="http://www.natpryce.com/articles/000785.html">Simplificators (Nat Pryce)</a> (Via <a href="https://twitter.com/trikitrok">@trikitrok</a>)</li></ul><p></p><p><br /></p><h2 style="text-align: left;">Thanks</h2><p>The post has been improved based on feedback from:</p><p></p><ul style="text-align: left;"><li><a href="https://twitter.com/georgina_not">@georgina_not</a></li><li><a href="https://twitter.com/islomar">@islomar</a></li><li><a href="https://twitter.com/pmareke">@pmareke</a></li><li><a href="https://twitter.com/msanjuan">@msanjuan</a> </li></ul><p></p><p></p><p>Thank you very much to all of you</p>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0tag:blogger.com,1999:blog-37251267.post-4672171681628898202023-03-16T10:23:00.000+01:002023-03-16T10:23:02.575+01:00Lean Software Development: Defer Commitment<p>Yesterday, I had the pleasure of presenting the talk "Lean Development: Defer Commitment" at the <a href="https://www.meetup.com/es-ES/madriagil/events/291768607/">Madridagil</a> offices. </p><p>I'm sharing the slides here in case they can be helpful to anyone.</p><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLsD3i-hrfDJXO-PIIve_ZueQkNpdKg3Nw_GFJjsMr3oxrxys7yKCxE1bihRiG2LyouGXhChdMGZQ8RzPnwn3rmldmmcFpuDGkNDk8X7bu4hbOQANrphwWKX3RHgMFZA41NnwGlNAISBpnVCpxq9bcxCrYNYyu0Jsqp5dN-IBwRTAghuQtug/s2048/FrSEzQFWcAAjzLY.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="922" data-original-width="2048" height="144" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLsD3i-hrfDJXO-PIIve_ZueQkNpdKg3Nw_GFJjsMr3oxrxys7yKCxE1bihRiG2LyouGXhChdMGZQ8RzPnwn3rmldmmcFpuDGkNDk8X7bu4hbOQANrphwWKX3RHgMFZA41NnwGlNAISBpnVCpxq9bcxCrYNYyu0Jsqp5dN-IBwRTAghuQtug/s320/FrSEzQFWcAAjzLY.jpeg" width="320" /></a></div><br /><p></p><p>Thank you very much to <a href="https://www.nexthink.com/"><b>Nexthink</b></a> for being such fantastic hosts.</p><div>
<iframe allowfullscreen="true" frameborder="0" height="569" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/e/2PACX-1vRCdM3KyEXy54jsf-T4jghvVH-K2pds7akribQpMNSTwk-JKXZ2wTo9nuyqT5kw0alUpzuakdjSRQSw/embed?start=false&loop=false&delayms=3000" webkitallowfullscreen="true" width="960"></iframe> </div><div>
<a href="https://docs.google.com/presentation/d/1Sfo88p9RvWlDZ7AuRjL7aEWCbZwijLNlAmCVL6GJRQ8/edit?usp=sharing">Link to the presentation</a> </div><div><br /></div><h3 style="text-align: left;">Related content
</h3><div><ul style="text-align: left;"><li><a href="https://www.eferro.net/2022/08/software-development-art-of-postponing.html">https://www.eferro.net/2022/08/software-development-art-of-postponing.html</a></li><li><a href="https://www.eferro.net/2022/04/system-control-its-evolution-or-be-its.html">Systems: Control its evolution / or be its slave</a></li><li><a href="https://www.eferro.net/2022/12/my-premises-about-software-development.html">My premises about software development</a></li></ul></div><div><br /></div>eferrohttp://www.blogger.com/profile/09351299557419046663noreply@blogger.com0