Move fast and fail fast

In software development, the mantra “move fast and fail fast” has become both a rallying cry and a source of considerable debate.

It champions rapid iteration, prioritizing speed and output, often at the perceived expense of meticulous planning and architectural foresight. This approach, deeply intertwined with the principles of agile development, presents a stark contrast to the traditional model of lengthy planning cycles, rigorous architecture design, and a focus on minimizing risk through exhaustive preparation.

Fail fast

The allure of “fast” is undeniable. In today’s competitive market, speed to market can be the difference between success and failure. Rapid prototyping allows for early user feedback, facilitating continuous improvement and ensuring the product aligns with real-world needs. In essence, it’s about validating hypotheses quickly and pivoting when necessary. This iterative approach, inherent in agile methodologies, fosters a culture of adaptability and responsiveness, crucial in environments where change is the only constant.

So, “fail fast” refers mostly to a fast validation of the MVP (minimum viable product) and drop it if the results are unsatisfactory. This is, in general, very good because it is an optimal usage of resources.

Speed vs. Integrity

However, the emphasis on speed can raise legitimate concerns, particularly regarding security and long-term architectural integrity.

The fear is that a “move fast” mentality might lead to shortcuts, neglecting essential security considerations and creating a foundation prone to technical debt.

This is where the misconception often lies: “fast” in this context does not necessitate “insecure” or “bad.” Rather, it implies a prioritization of development output, which can, and should, be balanced with robust security practices and a forward-thinking architectural vision.

But, how can this forward-thinking be achieved, when the team is focused mostly on delivering value to validate with customers the assumptions made?

The key lies in understanding that agile development, when implemented effectively, incorporates security and architecture as an integral part of the process.

Concepts like “shift left security” emphasize integrating security considerations early in the development lifecycle, rather than as an afterthought.

Automated security testing, continuous integration/continuous deployment (CI/CD) pipelines with security gates, and regular security audits can be woven into the fabric of rapid development, ensuring that speed does not compromise security.

Validating early in the process means also that the not only the product is proven to meet the expectations, but also the architecture it is built upon.

The traditional approach

On the other hand, the traditional approach, with its emphasis on extensive planning and architecture, offers the perceived stability of a well-defined blueprint.

However, this approach carries its own risks. The extended planning phase can lead to delays, rendering the final product obsolete by the time it reaches the market. Moreover, the rigid nature of pre-defined architectures can hinder adaptability, making it difficult to respond to unexpected changes in user needs or market dynamics. The risk of “failing due to delays and lack of adaptation” is a real threat in fast-paced environments.

The modern software developer must navigate this tension, finding a balance between speed and stability. This involves adopting a pragmatic approach, leveraging the benefits of agile methodologies while mitigating the associated risks.

This can involve:

• Establishing clear security guidelines and incorporating them into the development process. Having a SSDLC is mandatory when having to deliver fast.
• Prioritizing a modular and adaptable architecture that can evolve with changing requirements. Modules should be possible to be implemented quickly and dropped without a lot of pain if they prove to be unsuccessful.
• Implementing robust testing and monitoring to identify and address issues early on. A CI/CD pipeline will allow the team to focus more on delivering new features than testing and integrating all the time.
• Fostering a culture of continuous learning and improvement, where developers are encouraged to experiment and innovate, while also being accountable for security and quality.
• Utilizing threat modeling and risk assessment early in the design process. Threat modeling contains a risk assessment, which when done properly will prevent major issues later.

Instead of Conclusions:  my experience

Ultimately, the most effective approach is not about choosing between “fast” and “slow,” but about finding the right cadence of delivering value for each specific project .

The goal is to deliver constantly small pieces of code that bring value while avoiding failure altogether. If deliverables are constantly validated, a failure can only be of a small deliverable increment, which can be either quickly improved, completely removed or entirely replaced with something else.

Important is to learn from it quickly and adapt, ensuring that software development remains a dynamic and evolving process.

When I run a project, I define the goal and the high level path to achieve that goal. Sometimes this path is clear, sometimes many experiments are needed, and some will fail, some will succeed.