Anticipated Failure Design (DAF - Diseño Anticipado al Fallo)

What is DAF? DAF (Diseño Anticipado al Fallo - Anticipated Failure Design) is not a certifiable methodology, nor an academic paper. It's a mindset born from chaos, from the unexpected bug in production, from the system that fails during a live demo. DAF proposes thinking about errors before they happen. Designing to fail gracefully, without losing control. It's not about avoiding errors, but about embracing them from the design so that the system doesn't collapse. Why DAF? Because we're tired of working with the fear of bugs. Because failing is normal, but not preparing is negligence. DAF arises from the need to make software more human, more robust, more empathetic. To understand that errors are part of the process, not enemies to be avoided. The 6 Pillars of DAF 1. Centralization of Errors The system must scream loud and clear when something fails. No more scattered logs or silenced errors. Centralize from the design. Example: Instead of saying "something went wrong with payments," DAF demands you say: "Provider X did not respond due to insufficient balance." Clear, actionable. 2. Failure Classification Not all errors are the same. DAF promotes labeling them from the design. Example: Is it the user's fault, the network's, the system's, or the provider's? Classification allows for automatic decision-making, without drama. 3. Transparency for Everyone DAF believes in empathy. If something fails, the client should understand what happened, without technical jargon or magic codes. Example: Not "500 internal error," but: “Problems with external authentication. Try again in 5 minutes.” 4. Resilience from Design Retries, timeouts, fallbacks should not be patches. They are part of the design. DAF forces you to think about them from the start. Example: If the message bus goes down, you should already have retry and alert logic. Don't wait to lose data to implement it. 5. Guided Solution The system should not only scream, it should provide clear clues. Example: If the user sends a field incorrectly, don't just return a 400. Say: "The paymentDate field must have the format yyyy-MM-dd." 6. Continuous Improvement Based on Errors Every failure leaves a lesson. DAF proposes documenting them, analyzing them, and redesigning what is necessary. Example: A recurring bug in dates led to standardizing validations from the contract. Fewer errors, more speed. What DAF is NOT DAF is not TDD. It doesn't seek to test what you expect, but to prevent the unexpected. Nor is it a closed methodology. It's an adaptable mindset. "While TDD focuses on verifying expected behavior through unit tests, DAF focuses on anticipating and handling unexpected error scenarios at the design level." Who is DAF for? For everyone involved in the software lifecycle: developers (fewer surprise bugs), QAs (more effective testing), PMs (more reliable products), and UX designers (less frustrated users). Because when errors are anticipated in the design, the quality of the product improves and the team's stress decreases, allowing everyone to sleep more soundly. A Simple Order from Chaos DAF doesn't reinvent the wheel. It's about taking the best of various ideas (like Resilience Engineering, DevOps thinking, and the focus on User Experience) to build software from the reality of day-to-day work: chaos. Just as chaos theory tells us that even in the most disordered systems an underlying order emerges, DAF seeks to design systems that, even when they fail, do so in a clear and controlled way for everyone, from the technical team to the end-user. Thank you for reading! I hope this introduction to DAF has been helpful and inspiring. What do you think about designing for failure? Share your thoughts in the comments! [Hector Jaime - Mapache] "Because errors are not the end, they are the beginning of good design." www.linkedin.com/in/hectorjaimedmz

May 9, 2025 - 02:11

Anticipated Failure Design (DAF - Diseño Anticipado al Fallo)

What is DAF?

DAF (Diseño Anticipado al Fallo - Anticipated Failure Design) is not a certifiable methodology, nor an academic paper. It's a mindset born from chaos, from the unexpected bug in production, from the system that fails during a live demo.

DAF proposes thinking about errors before they happen. Designing to fail gracefully, without losing control. It's not about avoiding errors, but about embracing them from the design so that the system doesn't collapse.

Why DAF?

Because we're tired of working with the fear of bugs. Because failing is normal, but not preparing is negligence.

DAF arises from the need to make software more human, more robust, more empathetic. To understand that errors are part of the process, not enemies to be avoided.

The 6 Pillars of DAF

1. Centralization of Errors

The system must scream loud and clear when something fails. No more scattered logs or silenced errors. Centralize from the design.

Example: Instead of saying "something went wrong with payments," DAF demands you say: "Provider X did not respond due to insufficient balance." Clear, actionable.

2. Failure Classification

Not all errors are the same. DAF promotes labeling them from the design.

Example: Is it the user's fault, the network's, the system's, or the provider's? Classification allows for automatic decision-making, without drama.

3. Transparency for Everyone

DAF believes in empathy. If something fails, the client should understand what happened, without technical jargon or magic codes.

Example: Not "500 internal error," but: “Problems with external authentication. Try again in 5 minutes.”

4. Resilience from Design

Retries, timeouts, fallbacks should not be patches. They are part of the design. DAF forces you to think about them from the start.

Example: If the message bus goes down, you should already have retry and alert logic. Don't wait to lose data to implement it.

5. Guided Solution

The system should not only scream, it should provide clear clues.

Example: If the user sends a field incorrectly, don't just return a 400. Say: "The paymentDate field must have the format yyyy-MM-dd."

6. Continuous Improvement Based on Errors

Every failure leaves a lesson. DAF proposes documenting them, analyzing them, and redesigning what is necessary.

Example: A recurring bug in dates led to standardizing validations from the contract. Fewer errors, more speed.

What DAF is NOT

DAF is not TDD. It doesn't seek to test what you expect, but to prevent the unexpected. Nor is it a closed methodology. It's an adaptable mindset.

"While TDD focuses on verifying expected behavior through unit tests, DAF focuses on anticipating and handling unexpected error scenarios at the design level."

Who is DAF for?

For everyone involved in the software lifecycle: developers (fewer surprise bugs), QAs (more effective testing), PMs (more reliable products), and UX designers (less frustrated users). Because when errors are anticipated in the design, the quality of the product improves and the team's stress decreases, allowing everyone to sleep more soundly.

A Simple Order from Chaos

DAF doesn't reinvent the wheel. It's about taking the best of various ideas (like Resilience Engineering, DevOps thinking, and the focus on User Experience) to build software from the reality of day-to-day work: chaos. Just as chaos theory tells us that even in the most disordered systems an underlying order emerges, DAF seeks to design systems that, even when they fail, do so in a clear and controlled way for everyone, from the technical team to the end-user.

Thank you for reading! I hope this introduction to DAF has been helpful and inspiring. What do you think about designing for failure? Share your thoughts in the comments!

[Hector Jaime - Mapache]
"Because errors are not the end, they are the beginning of good design."
www.linkedin.com/in/hectorjaimedmz