Podcast: AI as an Amplifier. Why Engineering Practices Matter More Than Ever

Vasco Duarte invited me to be part of the Scrum Master Toolbox Podcast's AI Assisted Coding series, and I couldn't pass up the chance to talk about something I've been living and thinking about intensely for the past several months.

The conversation builds directly on the experiment I documented in Fast Feedback, Fast Features: My AI Development Experiment: 424 commits over 11 weeks, where for every unit of effort I put into new features, I invested four times more in refactoring, cleanup, tests, and simplification. And yet, globally, I think I more or less doubled my pace of work.

In the episode, we dig into several things I've been exploring:

Vibe coding vs production AI development. Both are valid—but they require different mindsets. Vibe coding is flow-driven, exploration-focused, great for prototypes and discovery. Production AI coding demands architectural thinking, security analysis, and sustainability practices. Even vibe coding benefits from engineering discipline as soon as experiments grow beyond a weekend hack.

The positive spiral of code removal. One of the most powerful patterns I've discovered is using AI to accelerate deletion. Connect product analytics to identify unused features, use AI to remove them efficiently, and you trigger a cycle: simpler code makes architecture changes cheaper, cheaper architecture changes enable faster feature delivery, which creates more opportunities for simplification. Humans historically avoided this because removal was as expensive as creation. That excuse is gone.

Preparing the system before introducing change. Rather than asking "implement this feature," I've been asking "how should I change my system to make this feature trivial to introduce?" AI makes that preparation cheap enough to do routinely. The result: systems that evolve cleanly rather than accumulating debt with each addition.

AI as an amplifier—the double-edged sword. This is the central idea. AI doesn't replace engineering judgment; it magnifies its presence or absence. Strong teams will see accelerated improvement. Teams without good practices will generate technical debt faster than ever. The path to excellence in modern software development lies in the seamless integration of a high-performance engineering culture, lean-agile product strategies, and an evolutionary approach to architecture. AI makes that path wider—but you still have to choose to walk it.

🎙️ Listen to the episode: AI as an Amplifier—Why Engineering Practices Matter More Than Ever

Stop Building Software. Start Cultivating It

There's a pervasive anxiety in the software industry. It's the feeling of never being good enough, of working late with the constant worry that what you just shipped will explode in production. It's the pressure to go faster, even when you know you're sacrificing quality. It's the frustration of feeling unprofessional, of never quite reaching a state of sustainable, high-impact work. Many of us have been there, living with this constant, low-grade stress.

But there is a better way. There is a path to professional tranquility that also delivers greater business impact. It doesn't come from a new framework or the latest methodology, but from a fundamental shift in how we think about our work. After nearly three decades in this industry, I've come to rely on five counter-intuitive but powerful mindset shifts.

1. Stop "Building" Software. Start Cultivating It.

One of the most damaging ideas I've encountered in our industry is the metaphor of software development as construction. We talk about "building" applications like we build houses. This metaphor is flawed, and it is the root cause of immense dysfunction.

It's harmful because it implies a static, finished product. A house, once built, is largely done. This mindset separates the "building" phase from a supposedly smaller "maintenance" phase. It leads to the absurd but common belief that software must be thrown away and completely rebuilt every few years.

We need a new metaphor: software as something that evolves, like a garden or a living system. It must be cultivated and guided. The single greatest advantage of software is its malleability, its ability to change. The construction metaphor negates this core strength. We are not masons laying permanent bricks; we are gardeners tending to a system that must constantly adapt to its environment.

If we saw the nature of software as something more evolutionary, as something that is alive, as a system that we are modifying all the time... that metaphor seems to me to be much more in line with the real nature of software development.

2. Your Most Valuable Contribution Might Be the Code You Didn't Write

Our industry often rewards the wrong things. Résumés are filled with lists of technologies used and massive projects "built." Productivity is mistakenly measured by the quantity of code written. More features, more complexity, and more lines of code are seen as signs of progress.

The truth is that true impact often comes from simplification. The most valuable work an engineer can do is often invisible. It's achieving an 80/20 solution that delivers most of the value with a fraction of the effort. It's proposing a simpler path that avoids a six-month project. It's having the courage to delete a feature that adds more cost than value.

Every feature, every line of code, has a "basal cost", an ongoing tax on the system. It adds to the cognitive load for new developers, increases maintenance, and creates friction that slows down all future innovation. The best engineers are masters of preventing unnecessary complexity. Their biggest wins, a disastrous project averted, a legacy system retired, will never appear on a performance review, but they are immensely valuable.

3. Agility Is a Strict Discipline, Not a Free-for-All

The word "Agile" has been misinterpreted to the point of becoming meaningless in many organizations. Teams use "delivering value" as an excuse for shipping shoddy work at high speed. For others, "being agile" has come to mean "anything goes", no documentation, no planning, no rigor.

This interpretation is a complete departure from the concept's original intent. True agility is a difficult and demanding discipline. It is not a shortcut or an excuse for chaos. It is a rigorous commitment to practices that enable sustainable speed and responsiveness.

In my head, agility is equivalent to a discipline, and a difficult one at that... a discipline of "Hey, I'm going to write the test first, then I'll do the implementation, then I'll refactor, I'll even eliminate functionalities that aren't useful." It's actually a tough discipline.

This discipline is embodied in concrete, systematic practices. On the technical side, it means Test-Driven Development (TDD) as the foundation for design and quality, Continuous Integration (CI) and Continuous Delivery (CD) to enable rapid, safe deployment, and continuous refactoring to keep the codebase simple and maintainable. On the product side, it means applying Lean Product Development principles to validate ideas before committing to full implementation, running experiments to test hypotheses, and ruthlessly prioritizing based on real user feedback.

But as the above highlights, it's not just about additive practices. It's also a discipline of subtraction, of proactively controlling technical debt before it becomes a crisis, of simplifying systems even when they're "working," and of removing features that don't add value. The goal is to maintain agility, both from a technical perspective (the codebase remains easy to change) and from a product perspective (the team can pivot based on what they learn).

These are not optional extras; they are the very foundation of agility. They require an uncompromising commitment to quality, because it is only through high quality that we can earn the ability to move fast, adapt, and innovate sustainably over the long term.

4. Individual Performance Metrics Are a Trap

There is a growing and dangerous trend of trying to measure individual developer productivity with simplistic metrics like the number of commits, pull requests, or story points completed. This approach is devastating. In 2023, McKinsey published an article proposing a framework to measure individual developer productivity using metrics like "contribution analysis" and "inner/outer loop time spent." The response from the software engineering community was swift and unequivocal. Kent Beck, creator of Extreme Programming, called it "absurdly naive," while Kent Beck and Gergely Orosz wrote a detailed rebuttal explaining why such frameworks do far more harm than good.

The problem isn't just with McKinsey's specific approach. It's with the entire premise of measuring individuals in a collaborative discipline. This is a direct application of Taylorism, the management philosophy developed by Frederick Winslow Taylor in the early 1900s for factory work. Taylorism treats people as interchangeable resources to be optimized locally, decomposing work into specialized tasks and measuring each person's individual output. It took manufacturing 50 years to move past this thinking. Yet in software development, a creative, knowledge-based discipline where these ideas are least effective, we continue to apply them universally.

When you incentivize local optimization through individual metrics, the negative results are entirely predictable. As W. Edwards Deming taught, over 90% of an organization's performance is a result of the system, not the individuals within it. But individual metrics create perverse incentives that optimize for the wrong things. We reward behaviors that are easy to measure but destructive to the whole: a high number of commits (encouraging smaller, more frequent check-ins regardless of value), celebrating people for "being 100% busy" (even if they're blocking others), or lionizing "heroes" who constantly put out fires (often of their own making). These incentives inevitably lead to chronic bottlenecks, constant rework, and a toxic hero culture where knowledge is hoarded and collaboration is discouraged.

It is devastating because it promotes individualism in a profession that is fundamentally about collaborative problem-solving. It discourages essential practices like pair programming because it makes it harder to assign "credit." It optimizes for busy-ness (output) instead of actual business results (impact). As Beck and Orosz point out, measuring effort and output is easy, but it changes developer behavior in ways that work against the outcomes that actually matter.

Software development is a team sport centered on learning. The true measure of performance is the impact and health of the team. The most valuable person on a team would often score terribly on these individual metrics. They might be the "glue" that holds everyone together, the mentor who elevates the skills of others, the person who prevents bad code from ever being written, or the engineer who just deleted 10,000 lines of obsolete code, making the system simpler for everyone. Their contribution is profound, yet these metrics would render them invisible or, worse, label them a poor performer.

5. Don't Ask for Permission to Be a Professional

Too many engineers wait for permission to do their job properly. They see quality practices like writing automated tests as something they need to negotiate or justify to management. This is a fundamental mistake.

You don't ask your manager for permission to use a for loop or a recursive function; you use the right tool for the job because you are a professional. Writing tests is the same. It is a non-negotiable, foundational part of professional software development, not an optional feature you need to bargain for.

This responsibility extends beyond just testing. Your job is not merely to execute instructions. It is to solve problems. That means taking the initiative to understand the "why" behind a feature, respectfully challenging requirements that don't make sense, and proposing simpler, better solutions. This isn't overstepping; it is the very core of engineering. By taking this professional responsibility, you build trust, earn autonomy, and position yourself to make a real, lasting impact.

Conclusion: A More Sustainable Future

The key to a more sustainable, impactful, and professionally satisfying career is to abandon the "construction" mindset. When we stop thinking of ourselves as builders of static artifacts and start seeing ourselves as cultivators of living, evolving systems, everything changes.

This single shift in perspective is the thread that connects all five of these principles. It leads us to value subtraction over addition, to embrace discipline over chaos, to measure team impact over individual output, and to take ownership of our professional standards. It is the path away from anxiety and toward durable, meaningful work.

The arrival of AI does not invalidate these principles; it reinforces them. If anything is going to change, it's that these mindset shifts will become more critical, not less. When we can generate code faster than ever, distinguishing between building and cultivating becomes more important than ever. When AI can produce features at unprecedented speed, knowing what NOT to build becomes the differentiating skill. The tools evolve, the disciplines adapt, but the goal remains constant: sustainable impact over time, real value delivered, and complexity kept under control. Now we have new tools and evolving disciplines, but they're still pursuing the same fundamental objective.

What is one "construction" habit you can challenge in your team this week to start cultivating your software instead?

References

• Stop Building Waste: 6 Principles for High-Impact Engineering Teams Eduardo Ferro (2025)
  eferro.net/stop-building-waste
  A complementary piece exploring how to maximize outcomes while minimizing software complexity.
• Perverse Incentives, Predictable Results: When Your System Sabotages Your Teams Eduardo Ferro (2025)
  eferro.net/perverse-incentives
  Explores how Taylorist thinking creates perverse incentives in software development and offers systemic solutions.
• Measuring developer productivity? A response to McKinsey Kent Beck and Gergely Orosz (2023)
  Kent Beck's version | Gergely Orosz's version
  A detailed rebuttal to McKinsey's framework, explaining why measuring effort and output damages engineering culture.
• Yes, you can measure software developer productivity McKinsey (2023)
  mckinsey.com
  The original McKinsey article proposing individual developer productivity metrics.
• Basal Cost of Software Eduardo Ferro (2021)
  eferro.net/basal-cost-of-software
  Introduces the concept of ongoing cognitive and maintenance costs each feature adds to a system.
• Extreme Programming Explained: Embrace Change Kent Beck (1999, 2nd Ed. 2004), Addison-Wesley
• Software has diseconomies of scale – not economies of scale Allan Kelly (2015, revised 2024)
  allankelly.net/archives/472
• The Most Important Thing Marty Cagan (2020), Silicon Valley Product Group
  svpg.com/the-most-important-thing

Pseudo TDD with AI

Exploring Test-Driven Development with AI Agents

Over the past few months, I've been experimenting with a way to apply Test-Driven Development (TDD) by leveraging artificial intelligence agents. The goal has been to maintain the essence of the TDD process (test, code, refactor) while taking advantage of the speed and code generation capabilities that AI offers. I call this approach Pseudo TDD with AI.

How the Process Works

The AI agent follows a set of simple rules:

1. Write a test first.
2. Run the test and verify that it fails.
3. Write the production code.
4. Run the tests again to verify that everything passes.

I use the rules I defined in my base setup for augmented coding with AI. With these base rules, I can get both the Cursor agent and Claude Code to perform the TDD loop almost completely autonomously.

The refactoring part is not included automatically. Instead, I request it periodically as I observe how the design evolves. This manual control allows me to adjust the design without slowing down the overall pace of work.

Confidence Level and Limitations

The level of confidence I have in the code generated through this process is somewhat lower than that of TDD done manually by an experienced developer. There are several reasons for this:

• Sometimes the agent doesn't follow all the instructions exactly and skips a step.
• It occasionally generates fewer tests than I would consider necessary to ensure good confidence in the code.
• It tends to generalize too early, creating production code solutions that cover more cases than have actually been tested.

Despite these issues, the process is very efficient and the results are usually satisfactory. However, it still doesn't match the confidence level of fully human-driven TDD.

Supporting Tools

To compensate for these differences and increase confidence in the code, I rely on tools like Mutation Testing. This technique has proven very useful for detecting parts of the code that weren't adequately covered by tests, helping me strengthen the reliability of the process.

Alternative Approaches Explored

In the early phases of experimentation, I tried a different approach: directing the TDD process myself within the chat with the AI, step by step. It was a very controlled flow:

"Now I want a test for this."
"Now make it pass."
"Now refactor."

This method made the process practically equivalent to traditional human TDD, as I had complete control over every detail. However, it turned out to be slower and didn't really leverage the AI's capabilities. In practice, it worked more as occasional help than as an autonomous process.

Next Steps

From the current state of this Pseudo TDD with AI, I see two possible paths forward:

1. Adjust the rules and processes so the flow comes closer to human TDD while maintaining AI speed.
2. Keep the current approach while observing and measuring how closely it actually approximates a traditional TDD process.

In any case, I'll continue exploring and sharing any progress or learnings that emerge from this experiment. The goal is to keep searching for that balance point between efficiency and confidence that collaboration between humans and AI agents can offer.

Related Content

• My Base Setup for Augmented Coding with AI
• Mutation Testing: When "Good Enough" Tests Weren't
• When AI Makes Good Practices Almost Free

Lean Software Development: Deliver as Fast as Possible

One of the fundamental principles of Lean Software Development is to deliver value as quickly as possible. However, this does not simply mean increasing the pace of work but rather optimizing the flow of value—delivering frequently, obtaining feedback, and using it to constantly adapt, thereby improving efficiency in value delivery. 

Let's explore how to achieve this by adjusting processes to move efficiently and confidently. 

Speed and Direction: It’s Not Just About Developing Faster

Being more efficient is not about building more (see The Building Fallacy) or always staying busy (resource efficiency, see The Resource Utilization Trap). Speed, in physical terms, has a direction, and moving fast in the wrong direction is the greatest waste we can have (see Eliminating Waste in Development). To move in the right direction, we need: 

• Continuous Deployment: To obtain frequent feedback.
• Humility: To accept that we do not always know what the customer needs or what the best technical solution is.
• Adaptation: Constantly adjusting our technical and product direction based on the feedback we receive.

Developing quickly without acting or deciding based on feedback is like running in circles. We exhaust ourselves but make no real progress. In fact, it’s even worse because we accumulate Basal Cost without any benefit (see The Basal Cost of Software).

How Fast is Fast?

From a practical perspective, moving fast means:

• Taking very small steps in development and delivery (see Developing Software: Postponing Decisions and Working in Small Steps).
• Ensuring that these steps last between a few hours (technical segmentation) and a day or a day and a half (product increments).

This allows us to deploy multiple times a day. Deploying this frequently requires doing so on demand, safely, and quickly. In an ideal world, these deliveries would be directly to the end customer. However, depending on the context, direct deployment to customers may not always be possible, or it may only be feasible for certain users (e.g., in embedded systems development or operating system components). These cases should be the exception (see Jocelyn Goldfein’s Model).

About 15 years ago, at Alea Soluciones, we deployed to production between three and five times per week, which was reasonable considering we were working with systems installed in our customers' data centers. Later, at companies like The Motion, Nextail, and ClarityAI—cloud-based multi-tenant environments—the teams I worked with achieved multiple deployments per day.

In all these cases, we reached this delivery speed using Trunk-Based Development, TDD, Continuous Integration, and pairing/mob programming, applying practices from eXtreme Programming (XP).

Control and Speed: The Right Balance

As Canadian Formula 1 driver Gilles Villeneuve said: "If everything seems under control, you’re not going fast enough." ;)

Having everything under control may seem ideal, but in reality, it’s a sign that you could be moving faster. How much faster? Until you start noticing some failures. This idea is key when developing software at high speed.

In my experience, when working with TBD, TDD, and Continuous Delivery, confidence in the process grows, and you start accelerating—delivering faster and faster. Inevitably, a mistake will happen. However, by working in small increments, the risk is low, and fixing the issue is usually quick. After correcting the error, it’s common for the team to slightly reduce speed.

This cycle of accelerating, learning, and adjusting is normal and, in my opinion, is a sign of a healthy team that continuously improves while maintaining a high delivery pace.

The Need for Robust Deployment Pipelines

In Lean, the flow of value begins with an idea or experiment we want to implement or validate and ends when we have delivered the increment, obtained feedback, and are ready to evaluate and decide on the next steps.

While Lean Manufacturing promotes reducing variability to standardize and optimize flow, in Lean Product Development or Lean Software Development, not all phases require low variability. For example:

• At the beginning of the value stream, experimentation and creativity are needed to generate diverse ideas and approaches.
• At the end of the cycle, we analyze feedback to decide what adjustments to make.

However, in the systematic process of deploying to production, we must minimize variability. This phase should be fast, solid, and reliable—something we can trust completely.

The goal is for deployments to be boring, a routine task that runs on autopilot.

To achieve this, deployment pipelines should have the following characteristics:

• Fast (<10 minutes) and reliable.
• Provide a high level of confidence in the solution through good automated tests.
• No flaky tests—unstable tests should not exist.

This is only possible if we treat deployment pipelines as first-class citizens in our system, developing and maintaining them with the same level of quality as the rest of the system.

Continuous Deployment: The Most Efficient Method

Ideally, the changes we make should be deployed to production individually, one after another. This allows us to obtain feedback quickly and deliver continuous value increments. As mentioned in this article and previous ones, this way of working provides major benefits:

• We continuously adjust course based on feedback.
• Mistakes have a low impact since they involve small changes and are easy to roll back.
• Understanding errors is simpler because the changes causing them are more limited in scope.

However, deploying is not free—it has an associated cost. It requires investment in:

• Developing automated deployment pipelines.
• Wait time every time we run the pipeline.

This cost is called the “transaction cost,” and when it is high, it limits how fast we can deliver.

Keeping Transaction Costs Low

Lean Software Development recommends keeping transaction costs as low as possible. To achieve this, it is essential to:

• Invest in automated deployment pipelines.
• Use automated tests that allow us to go directly to production if they pass.

This provides the confidence needed to deploy without manual intervention and ensures quality in every production release.

In the teams I have worked with, our default approach is Continuous Deployment. This means that any change committed to the main branch goes directly to production. To achieve this, we separate deployment from release using feature toggles, allowing us to roll out new features in a controlled manner, without making them immediately visible to end users.

Additionally, we have kept our deployment pipeline execution times between 10 and 15 minutes, ensuring that the delivery cycle remains agile and does not disrupt the workflow. If something fails, we typically implement an automatic rollback when post-deployment smoke tests detect an issue. This minimizes impact and ensures we can quickly regain control.

As Jez Humble, Joanne Molesky, and Barry O'Reilly highlight in Lean Enterprise:

"The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs."

This approach allows us to confidently make small changes, accelerate delivery times, and reduce risk and error costs.

Conclusions

To deliver value quickly in Lean Software Development, it is crucial to optimize the workflow without compromising quality. Speed does not mean working faster without control but rather continuously adjusting based on feedback, allowing for constant adaptation. Teams following this philosophy achieve continuous and secure deliveries, minimizing risks and maximizing value.

Key Principles:

• Small, frequent steps: Delivering in small increments reduces risk and makes error correction easier.
• Low transaction costs: Investing in fast, reliable deployment pipelines maintains speed without affecting quality.
• Continuous feedback: Rapid delivery enables constant feedback, improving and adapting the product.
• Confidence in quality: With automated testing and a solid delivery flow, teams can be sure that each iteration releases a robust product.

In summary, this approach not only optimizes value delivery but also allows teams to operate sustainably, with fast adjustments and minimal error impact.

Related Resources

• The Building Fallacy
• The Resource Utilization Trap
• Eliminating Waste in Development 
• Basal Cost of software
• Developing Software: Postponing Decisions and Working in Small Steps
• Lean Enterprise: How High Performance Organizations Innovate at Scale
• Continuous Delivery

Lean Software Development: Entregar lo más rápido posible

Uno de los principios fundamentales de Lean Software Development es entregar valor lo más rápido posible. Sin embargo, esto no significa simplemente aumentar el ritmo de trabajo, sino optimizar el flujo de valor, entregando con frecuencia, obteniendo feedback y usándolo para adaptarnos constantemente, mejorando así la eficiencia en la entrega de valor.

Vamos a explorar cómo lograrlo ajustando los procesos para movernos de manera eficiente y con confianza.

Velocidad y Dirección: No es sólo desarrollar más rápido

Ser más eficiente no se trata de construir más (ver The Building Fallacy), ni de estar siempre ocupados (eficiencia de recursos, ver The resource utilization trap). La velocidad, en términos físicos, tiene una dirección, y moverse rápido en la dirección equivocada es el mayor desperdicio que podemos tener (ver Eliminar desperdicios en el desarrollo). Para ir en la dirección correcta, necesitamos:

• Entrega continua (Continous Deployment): para obtener feedback frecuente.
• Humildad: para aceptar que no siempre sabemos lo que el cliente necesita ni cuál es la mejor solución técnica.
• Adaptación: ajustando constantemente nuestra dirección técnica y de producto en función del feedback que recibimos.

Desarrollar rápido sin actuar ni decidir en base al feedback es correr en círculos. Nos agotamos mucho, pero no avanzamos nada. De hecho, es aún peor, porque acumulamos Coste Basal sin ningún beneficio (ver El coste basal del software).

¿Qué tan rápido es rápido?

Ir rápido, desde un punto de vista práctico, significa:

•  Dar pasos muy pequeños en el desarrollo y la entrega (ver Desarrollando software posponiendo decisiones).
• Asegurarse de que estos pasos duren entre unas pocas horas (segmentación técnica) y un día o día y medio (incrementos de producto).

Esto nos permite desplegar varias veces al día. Desplegar con esta frecuencia implica hacerlo bajo demanda, de forma segura y rápida. En un mundo ideal, estas entregas serían directamente al cliente final. Sin embargo, dependiendo del contexto, puede que haya entornos donde el despliegue a los clientes finales no sea posible, o solo se pueda hacer a ciertos usuarios (por ejemplo, en el desarrollo de sistemas embebidos o componentes de sistemas operativos). Estos entornos deberían ser la excepción (ver el modelo de Jocelyn Goldfin).

Hace unos 15 años, en Alea Soluciones, salíamos a producción entre tres y cinco veces por semana, lo cual no estaba mal, considerando que se trataba de sistemas instalados en los centros de datos de nuestros clientes. Posteriormente, en empresas como The Motion, Nextail y ClarityAI, todos entornos cloud multi-tenant, los equipos con los que he trabajado lograban desplegar varias veces al día.

En todos estos casos, alcanzamos esa velocidad de entrega utilizando Trunk-Based Development, TDD, Integración Continua y pairing/mob programming, es decir, aplicando prácticas de eXtreme Programming (XP).

Control y Velocidad: El Equilibrio Correcto

Tal como dijo el piloto canadiense de Fórmula 1, Gilles Villeneuve: "Si todo parece bajo control, es que no vas lo suficientemente rápido" ;)

Tener todo bajo control puede parecer ideal, pero en realidad, es una señal de que podrías ir más rápido. ¿Cuánto más rápido? Hasta que comiences a notar algunos fallos. Esta idea es clave cuando hablamos de desarrollar software a alta velocidad.

En mi experiencia, al trabajar con TBD, TDD y entrega continua, la confianza en el proceso crece y empiezas a acelerar, entregando cada vez más rápido. Inevitablemente, cometerás un error. Sin embargo, al trabajar en pequeños incrementos, el riesgo es bajo y corregir el fallo suele ser rápido. Tras corregir el error, es común que el equipo reduzca ligeramente la velocidad. 

Este ciclo de acelerar, aprender y ajustar es normal y, en mi opinión, es un signo de un equipo saludable que busca mejorar continuamente mientras mantiene un alto ritmo de entrega.

Necesidad de solidez en los pipelines de despliegue

En Lean, el flujo de valor comienza con una idea o experimento que queremos implementar o validar, y finaliza cuando hemos entregado el incremento, obtenido feedback y estamos listos para evaluarlo y decidir los próximos pasos.  

Aunque en la manufactura Lean se promueve la reducción de la variabilidad como una forma de estandarizar y optimizar el flujo, en Lean Product Development o Lean Software Development no todas las fases deben tener baja variabilidad. Por ejemplo, al inicio del flujo de valor, se requiere experimentación y creatividad para generar ideas y enfoques variados. Lo mismo ocurre al final del ciclo, cuando analizamos el feedback para decidir qué ajustes realizar.

Por otro lado, en la fase correspondiente al proceso “sistemático” de poner en producción, debemos asegurarnos de que haya mínima variabilidad. Esta etapa debe ser rápida, sólida y confiable, algo en lo que podamos confiar sin problemas.  

El objetivo es que los despliegues sean aburridos, una tarea rutinaria que se ejecute en piloto automático.

Para ello, los pipelines de despliegue deben cumplir con las siguientes características:

• Ser rápidos (<10 minutos) y confiables.
• Ofrecer un alto grado de confianza en la solución mediante buenos tests automáticos.
• No permitir la existencia de tests inconsistentes (flaky tests).

Esto solo es posible si consideramos a los pipelines de despliegue como ciudadanos de primer nivel dentro de nuestro sistema, desarrollándolos y manteniéndolos con el mismo nivel de calidad que el resto del sistema.

Entrega continua (Continuous Deployment): El método más eficiente

Idealmente, los cambios que realizamos deberían desplegarse a producción de forma individual, uno detrás de otro. Esto nos permite obtener feedback rápidamente y entregar incrementos de valor de manera continua. Como mencionamos en este artículo y en algunos anteriores, esta forma de trabajar ofrece grandes ventajas:

• Ajustamos continuamente el rumbo basado en el feedback.
• Si cometemos un error, el impacto es bajo, ya que se trata de un cambio pequeño y es fácil recuperarnos al revertir a la versión anterior.
• Además, entender cualquier error es más sencillo, porque el cambio que lo pudo haber causado está más acotado.

Sin embargo, desplegar no es gratis, tiene un coste asociado. Requiere inversión en:

• Desarrollo de pipelines de despliegue automáticos.
• Tiempo de espera cada vez que ejecutamos el pipeline.

Este coste se denomina "coste de transacción", y cuando es alto, limita la velocidad con la que podemos entregar.

Mantener bajos los costos de transacción

Lean Software Development recomienda mantener el coste de transacción lo más bajo posible. Para conseguirlo, es fundamental:

• Invertir en pipelines de despliegue automáticos.
• Usar pruebas automatizadas que nos permitan ir a producción directamente si los tests pasan.

Esto nos brinda la confianza necesaria para desplegar sin intervención manual y garantiza la calidad en cada entrega a producción.

En los equipos en los que he trabajado, nuestra opción por defecto es el Deployment continuo. Esto significa que cualquier cambio que subimos a la rama principal va directamente a producción. Para lograrlo, separamos el deployment del release mediante feature toggles, lo que nos permite liberar nuevas funcionalidades de forma controlada, sin que estén visibles inmediatamente para los usuarios finales.

Además, hemos logrado mantener los tiempos de ejecución de nuestros pipelines de despliegue entre 10 y 15 minutos, asegurando que el ciclo de entrega sea ágil y no interrumpa el flujo de trabajo. Si algo falla, solemos implementar un rollback automático cuando los smoke tests post-despliegue detectan un problema. Esto minimiza el impacto y asegura que podemos recuperar rápidamente el control.

Como destacan Jez Humble, Joanne Molesky y Barry O'Reilly en Lean Enterprise:

"The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs."

Este enfoque nos permite trabajar con confianza en cambios pequeños, acelerar los tiempos de entrega, y reducir el riesgo y coste de errores.

Conclusiones

Para entregar valor rápidamente en Lean Software Development, es crucial optimizar el flujo de trabajo sin comprometer la calidad. La velocidad no implica trabajar más rápido sin control, sino ajustar continuamente en función del feedback, permitiendo una adaptación constante. Los equipos que siguen esta filosofía logran entregas continuas y seguras, minimizando riesgos y maximizando valor.

Los principios clave son:

• Pasos pequeños y frecuentes: Entregar en incrementos pequeños reduce el riesgo y facilita la corrección rápida de errores.
• Costes de transacción bajos: Invertir en pipelines de despliegue rápidos y fiables permite mantener la velocidad sin afectar la calidad.
• Feedback continuo: Entregar rápidamente permite recibir retroalimentación constante, lo que facilita mejorar y adaptar el producto.
• Confianza en la calidad: Con pruebas automatizadas y un flujo de entrega sólido, los equipos pueden estar seguros de que cada iteración libera un producto robusto.

En resumen, este enfoque no solo optimiza la entrega de valor, sino que también permite a los equipos operar de manera sostenible, con ajustes rápidos y minimizando el impacto de los errores.

Recursos relacionados

• The Building Fallacy
• The resource utilization trap
• Eliminar desperdicios en el desarrollo
• El coste basal del software
• Desarrollando software posponiendo decisiones
• Lean Enterprise: How High Performance Organizations Innovate at Scale
• Continuous Delivery

The Building Fallacy: A Misleading Metaphor in the Age of Continuous Evolution

The "building fallacy" in software development refers to the flawed comparison between creating software and constructing a physical building. While this analogy may seem intuitive at first glance, it breaks down when we consider the nature of software and the realities of today's technology landscape. This misconception leads to inefficient processes, increased costs, and diminished capacity for innovation.

Here's why this metaphor is misleading and why it's more critical than ever to abandon it:

Why the Building Metaphor Doesn’t Hold Up

Software is Evolutionary, Buildings are Static

Buildings are designed with a fixed endpoint in mind. Once constructed, they primarily require maintenance to address wear and tear. Software, however, exists in a state of constant change. To remain relevant, it requires ongoing adaptation in response to evolving user needs, market demands, and technological advancements. Software development is more like tending a garden than erecting a structure—it requires continuous nurturing, pruning, and adjustment to thrive.

Overemphasis on Upfront Design

The building analogy often leads teams to prioritize extensive upfront planning and design, mirroring the blueprints used in construction. However, in software development, excessive upfront design can stifle innovation and lead to the dreaded "waterfall" model, where changes become costly and time-consuming. A more iterative approach allows teams to learn and adapt based on real feedback, making decisions at the last responsible moment and incorporating the latest insights.

Ignoring the Long Tail of Costs

The building fallacy promotes the misconception that most of the effort lies in the initial "construction" phase. In reality, maintaining, evolving, and supporting software systems far outweighs initial development costs.

A crucial concept that challenges the building analogy is Basal Cost—the recurring expense of maintaining features or code regardless of usage. This includes updates, security patches, and the cognitive load of supporting the code. Ignoring these costs leads to an incomplete understanding of the true financial and resource implications of software development. See more at Basal Cost of software.

Why the Building Fallacy is More Problematic Than Ever

In today's rapidly evolving tech landscape, clinging to the building fallacy is more detrimental than ever. Here's why:

The Pace of Change is Relentless

Technology, user needs, and market dynamics are shifting at an unprecedented pace. Software must evolve quickly to stay relevant. A rigid, building-centric mindset makes it hard to adapt to new challenges or opportunities.

Increased Reliance on External Systems

Modern software heavily depends on external APIs, cloud services, and open-source libraries, all of which evolve constantly. The building analogy fails to account for the complexity of managing these dependencies and ensuring seamless integration over time.

The Rise of Continuous Delivery

Continuous delivery and DevOps practices emphasize frequent releases, rapid iteration, and tight feedback loops, clashing with the notion of a fixed endpoint or grand unveiling. These practices underscore the need for flexibility, not rigidity.

Shifting to an Evolutionary Mindset

To succeed in today's environment, teams must abandon the building fallacy and embrace software as a living, evolving system. This shift involves:

Prioritizing Learning and Adaptation

Software development should be seen as a continuous process of experimentation. This means adopting agile methodologies, prioritizing validated learning over feature delivery, and delaying decisions to incorporate the latest insights.

Designing for Change

Architectures should be modular, flexible, and loosely coupled, making it easier to adapt to new requirements, integrate evolving external systems, and experiment with new technologies.

Managing Basal Costs

Teams must actively manage Basal Costs throughout the software lifecycle by:

• Regular Maintenance: Keeping dependencies updated, applying security patches, and fixing bugs.
• Cognitive Load Management: Simplifying the codebase and documentation to reduce the mental effort for developers.
• Eliminating Unused Features: Removing unnecessary features to lower maintenance costs.
• Investing in Code Quality: Refactoring, code reviews, and automated testing to improve maintainability and manage Basal Costs over time.

Lean Software Development and Extreme Programming (XP) practices are particularly effective in keeping Basal Costs low. Lean principles focus on eliminating waste, such as unnecessary code or features that add no value, which reduces maintenance burdens. XP practices, like Test-Driven Development (TDD), continuous integration, and pair programming, promote clean, maintainable code and help prevent technical debt.

By adopting these practices and embracing a mindset of continuous evolution, teams can break free from the outdated building fallacy and create software that thrives in today's dynamic technology environment.

Related content:

• Basal Cost of software
• Lean Software development: The art of postponing decisions
• 🕮Modern Software Engineering Dave Farley
• 💻  Real Software Engineering Glenn Vanderburg

Top recommended Talks & Podcasts

(Real) Agile & Lean software development:

Product & Lean Product Development

 

Related pages

• Recommended Talks & Podcasts
• Recommended Agile/Lean talks
• Recommended Product Talks

How big is the backpack your organisation is holding

Author: Jorge Jardines https://www.gardenunez.net/

Every experiment, invalidated product feature or unused line of code you haven't deleted is adding weight to your backpack.

Every morning when you wake up and need to walk the next X miles you feel the weight in your back and you feel slower than yesterday. It is like adding an extra bottle of water on your backpack, water you aren't gonna drink but still needs to hold on your back.

Your team or organisation is holding this huge backpacks all the time. Do you ever wonder why adding a new experiment gets more and more slower and costly for your teams, do ever check how much code isn't being used, how many features are not being used I your product, how many "brilliant" ideas were transform into code that nobody used. Do you ever wonder how big is the backpack your organisation is holding.

References:

• It's not only waste; It's burden
• Basal Cost of software  
  

It's not only a waste; it's a burden

Talking about software systems, let's stop to talk about waste when we refer to something not necessary or created without a clear understanding of the problem to solve. Let's call it a burden (since you are going to have it holding you back forever)...

If you implement it to experiment, learn and later throw it away, perfect... If you are keeping it, you are fooling yourself. 

This code is a burden, worse than the sunk cost, and it will generate a recurrent cost forever.

There are two types of complexity, the inherent and the accidental/incidental.

The inherent complexity can't be avoided because it is intrinsic to the problem we want to solve. But the accidental/incidental is all the complexity we introduce by not fully understanding the problem, not knowing how to solve it, or by our lack of mastery on the subject, etc.
 

This accidental/incidental complexity is also a burden. The inherent one is not. :)

Do yourself a favor, reduce the burden. reduce the basal cost. improve your life and the life of your team.

Develop product in an agile way:

1. Work in small steps
2. Try to really understand the real problem and the meaningful impact you want to make
3. Validate each increment and its impact
4. Always work with quality-in and with attention to technical excellence
5. Refactor continuously (to reduce the accidental/incidental complexity)
6. And for God's sake, delete everything that is not necessary. Ruthlessly remove; code, dependencies, features, complexity… Minimize basal cost and make the evolution of the system easier.

And follow the principles:

• Continuous attention to technical excellence and good design enhances agility.
• Simplicity --the art of maximizing the amount of work not done-- is essential.

References:

• Basal cost of software 
• The Two Root Causes of Software Complexity
• Agile manifesto Principles
  
• talk Small Safe Steps (Spanish) 
  

A letter to Agile Coaches (Scrum, XP, and software delivery)

As you know, the Manifesto for Agile Development was created by some developers who believed that there was a better way to develop software than the one in widespread use at the time.
Surely you also know that this manifesto defines a different way of working and that it is not only valid for developing software.
The values and principles from the manifesto are valid for many creative endeavors. The great exponent of this way of working that has transcended throughout these years has been Scrum.

What perhaps nobody has told you (especially if you do not have a technical background) is that scrum is not a working methodology for software development so although it is very suitable for certain parts of the company, by itself is not enough for software development.

Precisely because it is a general-purpose framework, it has been able to expand without problem to many companies. The problem is that when applied to software development without any agile development practices, the result is usually a disaster not sustainable over time.

What an irony.  Developers come together to define how to develop software and 20 years later their ideas improve many types of work, except software development.

Some context to the manifesto, Scrum and XP

In the creation of the manifesto, there were representatives of Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

As we can see in the following photo a lot of the authors come from the XP community.

So to a large extent, when the authors referred to agile software development, they were referring to XP and other development practices that pursue technical excellence and simplicity as stated in the manifesto.

“Continuous attention to technical excellence and good design enhances agility.”
“Simplicity--the art of maximizing the amount of work not done--is essential.”

Moreover, in fact, Scrum was considered the ideal complement for agile software development (XP) to be scaled up and introduced in enterprises as we can read from the scrum creators:

“eXtreme Programming is an ideal many software shops would love to reach, but with the constant pressures to produce software quickly, they cannot actually implement it. ... This book shows readers how to use SCRUM, an Agile software development process, to quickly and seamlessly implement XP in their shop-while still producing actual software.” 

Book: “Agile Software Development with Scrum”

Ken Schwaber and Mike Beedle

If XP was so crucial for software development, why hasn't it been transmitted as actively as scrum?

The ideas of agility with XP practices are only valid for software development and are not valid for the rest of the company, while Scrum fits like a glove in any departments of any company.
There is another interesting fact, without engineering practices, it was easier to transmit to the management level. :)

“I learned from Jeff Sutherland that the first Scrum actually did all the XP practices. But Ken Schwaber convinced him to leave the engineering practices out of Scrum, to keep the model simple and let the teams take responsibility for the tech practices themselves. Perhaps this helped spread Scrum faster, but the downside is that a lot of teams suffer because they lack the technical practices that enable sustainable agile development.”

“Scrum and XP from the Trenches” Henrik Kniberg

So actually, the authors of the manifesto clearly understood that Scrum is not an agile development method and that you need XP to get the benefits of agility when you develop software.

“You don’t see high performing Scrum teams without XP engineering practices. It is difficult to scale XP teams without Scrum and Scrum solves the management interface issues for XP. Be careful about doing pieces of anything and calling it Agile.”

“Deep Agile course” Ron Jeffries and Jeff Sutherland

And what can I do as an Agile coach?

First, read the following references to understand the frustration that software developers have with the mainstream Agile:

• Developers Should Abandon Agile (Ron Jeffries)
• Agile is Dead (Long Live Agility) (Dave Thomas)
• Flaccid Scrum (Martin Fowler)

Second, you should understand and recognize the importance of software development nowadays (you know, now every company is a software company).

So Finally, with this context and knowing that you need agile development practices, try to introduce them getting the needed help. Contract an XP coach. Introduce XP practices.  Push for an agile architecture that helps to introduce DevOps practices. 

And remember...

we can't be agile if our code sucks.

Related:

• No Business Agility without Agile Software Delivery
• Agile is counterintuitive
• Don't blame the Manifesto for Agile Software Development

No Business Agility without Agile Software Delivery

Business agility is not possible only doing agile software delivery. Furthermore, business agility is impossible without doing agile software delivery.

The bad news is that using scrum without agile development practices is not agile software delivery (and will collapse faster than you think).

Agile software delivery:
- Requires to be capable to put in production and operate a continuous train of product increments during all the product life.
- Fast feedback for each step of the value stream.
- Requires automatic testing and requires to include quality in the process.
- Good feedback for the system in production (monitoring, observability, operability, etc).

So if you are a tech company (why every company is a technology company) and you want to improve your business agility, don't forget to improve your agile software delivery capacity. If you have doubts, DevOps and XP are a great start to complement your scrum process.

Related posts

• http://www.eferro.net/2018/07/agile-is-counterintuitive.html
• http://www.eferro.net/2018/04/dont-blame-manifesto-for-agile-software.html
• http://www.eferro.net/2016/08/agile-is-not-recipe-for-success.html

Honey Badger Team - Visual History III - CD as driving force

After publishing Honey Badger Team visual history, @artolamola asked me on twitter if I used "continuous delivery" as the driving force for the transformation and why. The short answer is Yes, and in this blog post will try to explain the motivations behind.

For me, agile requires two things (see the-two-pillars-of-agile-software):

• A healthy knowledge culture focused on people (collaboration, learning, respect, team work, creativity...) 
• Looking for quality and technical excellence (for example XP practices are a great starting point).

To introducing the healthy knowledge culture, I introduce retrospectives and worked as a facilitator,  change agent and "Developer Whisperer".

In our profession knowledge is the bottleneck

For the technical excellence I think that we should follow this steps:

• If there is a classic vicious cycle of bad quality or bad practices going on. We should stop and break this cycle immediately. The typical example consists in having technical debt, that generates bugs, that generate even more technical debt that ends in the complete collapse in few months.
• Assume that we have the capacity and very good intentions.
• Help to create a virtuous cycle to improve our technical quality day by day.
• To create this virtuous cycle we need to define a clear goal to align all of our efforts.

Vicious Cycle of technical debt :)

In our case, and having in mind that we are a cloud native product, I thought that we can use Continuous Delivery as our team Goal. 

Why Continuous Delivery?

The answer is that I thought that we require a good practice that force us to do the thing right and doesn't allow us to hide our unprofessionalism or incompetence. And for this, and in the cloud, I think that in our case Continuous Delivery will put a lot of pressure on doing the things right.

Continuous Delivery implies:

• Low cost and a smooth process for deployment that doesn't affect customers. This requires (or at least recommend) introducing DevOps, automation, rolling deploys and Continuous Integration.
• Having good confidence in our product. This requires Continuous Integration, Automatic testing, and Monitoring for production.
• Automatic testing requires integration tests and unit tests, and for sure, having unit tests put a lot of pressure on doing a good design (for example to have a hexagonal architecture or other architecture that decouple business logic from infrastructure).

So indirectly, trying to implement Continuous Delivery requires or recommend doing the following practices: DevOps, Infrastructure Automation, Zero down time deploys (for example rolling deploys), Continuous Integration (perhaps with trunk based development), Integration testing, Unit testing, Good Design (for example using hexagonal architecture).

Virtuous Cycle created when CD is the goal

Continuous Delivery doesn't allow you to hide bad technical quality and force you to introduce good technical practices and work very hard to have a healthy code base.

With this approach, we, as a team, improve a lot our technical knowledge, our code base and our practices. We have to improve many technical practices but we have already come a long way and I sincerely believe that we are going in the right direction. :)

Extraball:

• If you use micro services, CD force you to think about independent deployability.
• CD force you to learn how to make parallel changes (using feature toggles, database refactoring, etc.)
• Some additional insights from @artolamola:
• Above CD you can implement any agile method for team organization (scrum, kanban, etc.).
• CD force you to think how to decompose each feature in vertical slices.

References:

Some of these ideas come from:

• Competing On The Basis Of Speed Mary Poppendieck
• The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google Randy Shoup

Some context about how I understand agile:

• Agile is not a recipe for success...
• The two pillars of agile software
• Remove the excuses for not being a professional

The history of the Honey Badger team:

• honey badger team visual history
• honey badger team visual history II
• honey badger team

Socrates Canaries 2017, experience and notes

The past week I attended to my second Socrates Canaries (Software Craftsmanship and Testing Conference)... This posts summary the experience (things I have learned, ideas to explore, techniques to use...). The Socrates event is an open space, so whatever happens is the only thing that could have :)

Notes from the sessions:

Under the umbrella (elixir) @gemcfadyen

Interesting and very practical presentation about how to organize and structure elixir application using the umbrella concept (http://elixir-lang.org/getting-started/mix-otp/dependencies-and-umbrella-apps.html).  You have all the advantages of the microservices and you remove some of the cons because you bundle the services together with explicit dependencies. Georgine used https://github.com/gemcfadyen/umbrella_romanNumerals as example. She also commented https://github.com/elixirkoans/elixir-koans for learning elixir.

Craft thinking @mashooq

(Book Craftsman by Richard-Sennett)
Very interesting reflections on the crafts in general and the craft in the development of software. The ideas come from the book Craftsman (Richard-Sennett) and the interpretations from Mashooq. Great insights and very interesting discussion.
Some random notes:

• Craftsmanship. Human Impulse. The desire to do a job well for it's own sake.
• We should always consider "How" and "Why" we make something... 
• From "problem solving" to a combination of "problem finding + problem solving". Finding problems is also a skill to learn.
• Motivation matters more than talent
• We need imagination to learn. We also need fail (a very important note for mentors...)
• Learn to apply the minimal force needed (in software we should compare this idea with the use of frameworks... ;) )

Show your architecture @borillo @eferro (myself)

Ricardo and myself proposed this session... the idea was to show several architectures/designs and to discuss about the tradeoffs and decissions that generated each architecture. We discussed three designs, one from @borillo, another one from kuba and another one from myself (@eferro).
We discussed and explain why we create this design and what was the tradeoffs... I hope that this session was interesting for someone :)

The handsome crafters @eferro & @borillo in 'Tell us your Architecture'. :-) pic.twitter.com/kWN3VygwWG

— Antonio de la Torre (@adelatorrefoss) 7 de abril de 2017

Building learning teams

A round table about how we can introduce a learning culture in a software development team or company. This are some random ideas:

• Do food
• Lean coffee (initially with a meta topic or about a shared interests)
• Skill matrix
• Know your company
• Introducing learning time in work hours (with the possibility to extend after work hours). A good idea to this kind of learning is Lunch & Learn.
• The company pay pluralshight or similar but remove the service is not used. You don't use it, you lost it.
• Some reserved time: Give a tech talk, and as fallback, show a recorded talk and as a fallback a refactoring session or a mob programming session.

Personal productivity. @gardenunez

Another round table about how we can organize ourselves, as obsessive people, to be productive and not going mad in the process :)
Some tips about focus, pomodoro technique to deal with procrastination, making a list of the things that really matter, and so on...
And also some comments about not pushing to hard to ourselves... :)

Non Violent Communication Miguel Cruz

A good explanation about the how to have better relations and real connection using non violent communication. This kind of communication is a difficult skill that can be learned using the book Non Violent Communication book or going to a workshop or participating in some of the related communities (like the new created group in Barcelona).

The overall process consists in the following steps:

1. make the observation (without judgement)
2. express your feeling (it's difficult to separate feelings and opinions)
3. express your needs
4. making a request (in a concrete way). Is a request, not a demand, so it can be rejected.

The method is divided in three steps/levels:

1. Self empathy
2. Empathetic listening
3. Be able to express in an empathetic way

I already read the book, but it requires practice. This skill can change deeply your relationships and life... so it is no easy, but deserves the effort :)

Serverless with AWS Lambda @mashooq (I acted as host)

This was a session hosted by me to ask Mashooq about codurance's experience using AWS Lambda in production. The session was divided in two parts, the first one was a presentation about this codurance's project and the second one was a discussion to identify if in my use case, have sense or no to consider using lambda.

Some lessons:

• Bad choice for constant load
• Force you to focus on business code (not in infrastructure)
• Good base for security, scalability, performance
• 1º understand the lowlevel stuff using aws api or/and aws cli, before using any framework or abstraction (apex, claudia.js, etc)... 
• Prepare for runing localy from the day 0. Developing any mock/glue code needed. 
• For web servers:
• Latency problem to serving http request with JVM based languages. The startup/bootstrap process have a huge latency. They implement a periodic ping to avoid the stop of the containers, but this is not an elegant solution.
• If you serve the frontend (js, html, css) from CDN, is difficult to synchronize with backend code. They need to invalidate the CDN resources and this cost money.

Serverless:
cost model - request based (pay by request)
strong infrastructure abstraction.

Another alternative for a web application using a JVM, than also have a strong infrastructure abstraction is Elastic Beanstalk

The second part of the session was a conversation about the possibility to use lambda for my use case, but for this part I will generate another post when I make the initial testing... In summary, seems that Lambda can fit our problem, but we should make the calculations about cost.

Taming the monolith  @mashooq

This session gave some ideas about how we can divide a monolith and how we should have in mind where are the vector of changes, because there is no best approach, it always depend of the nature of the change/evolution request that our system have.
Two powerful ideas:

• Have in mind, at all levels, coupling and cohesion (for modular decomposition, to identify bounded contexts, to deine service limits, etc.)
• Include the user journey

Some random quotes from this session:

• "We need everybody to be architects" Mash
• "Architecture. Design that is difficult to change" Mash

Liquid modernity @jordianguela

The goal of this session was to discuss about how this concept of "liquidity" is affecting us. This concept was coined by the philosopher  Zygmunt Bauman that talked about globalization, modernity and postmodernity, consumerism and morality.

The process was, we show different phrases from Zygmunt and we discusses the meaning and the pros and cons. And interesting session.

The concept of minimalism also appeared as one way to deal with this amount of changes  (Lifestyle Minimalism - Renouncing Your Busy Stupid Life)

Vuex + IDDD @nestorsalceda, @gualison (from the codingstones)

As I have no experience at all with front-end I only attended for the first part of the session. They described how they approach the architecture for a front end application using Vuex and the concepts of IDDD... You can see the results at:

https://twitter.com/CodingStones/status/850753594668318720

They show the code and seems to be very simple and clean... a good stuff to research further.

PostgreSQL @juanignaciosl

A great presentation of the advances features of PostgreSQL... it seems to be the most powerfull DB... is the "Swiss army knife" of the databases... (relational, document oriented, pub/sub, with GIS extensions, rich data types...)
These are the slides of the presentation POSTGRESQL The one tool to bring to a desert island
Very instructive.

Other sessions, lightning talks and conversations:

• Mental health
• Different organizations (codesai) (book Reinventing Organizations)
• How the codingstones distribute the profits (codingstones)
• pointers in go
• gendered language
• carbon offset / climate change
• Mob programming sessions
• ...

Resource Corner

• Non Violent Communication by Marshall Rosenberg (Book, workshops, training...)
• Reinventing Organizations by Frédéric Laloux (Book)
• The art of destroying software by Greg Young
• How to get better at the things you care about by Eduardo Briceño (TED talk)
• SPIN Selling by Neil Rackham (Book)
• Start with why Simon Sinek (Book and TED talk)
• Coursera Learning how to learn
• DDD Fundamentals on pluralsight.com
• Thinking Fast and Slow Daniel Kaleman
• lazymanifesto.org and lazymanifesto.org/principles.html
• Neuland markers (for drawing and sketchnoting)
• The back of the napkin (book on drawing)
• Bikablo (books on drawing)
• The loudest duck Laura A. Liswood
• Is postgreSQL good enough? 
• Safe and unsafe operations for high volume PostgreSQL
• The Devops 2.0 toolkit by Viktor Farcic

Related links:

• https://www.socracan.com/
• https://en.wikipedia.org/wiki/Open_Space_Technology
• http://www.eferro.net/2015/03/socrates-canaries-experience-and-notes.html

Personal feelings and notes:

• Somehow I improved my English so I interacted more and with more people :)
• Old friend, new friends... I like this event... 
• Great idea to come with the family and use the event as excuse to have family time at Canaries.
• I returned home full of energy.
• Great to have more developers from TheMotion attending this kind of conferences... The Socrates is  a great introduction to the Software Craftmanship community and to the unconference format. Thank you @gardenunez for coming to this event.
• I love the open space format.

Thanks to the organizers, mainly @suuigd (Dani), @mangelviera (Miguel), the @CraftsmanshipGC community and to codesai.  
And of course to @eidrien for being the facilitator.