"Plan to throw one away; you will, anyhow" is one of the most quoted pieces of advice from Fred Brooks's *The Mythical Man-Month* (1975). Appearing in Chapter 11, the idea asserts that the first version of any software system is fundamentally a learning exercise. You cannot fully understand a problem until you have built a solution to it, and by then, you inevitably discover that your initial assumptions were wrong in important ways.
## The Core Argument
Brooks observed that in project after project, the first system built was barely usable. It was too slow, too big, too awkward, or simply wrong in its fundamental assumptions about how users would interact with it. Teams that planned to deliver their first attempt as the final product invariably ended up throwing it away anyway, but at greater cost because they had invested in polish, documentation, and deployment of a flawed design.
The practical advice was therefore to accept this reality and plan for it: build a **pilot system** explicitly intended as a prototype for learning, then build the real system informed by everything the pilot taught you. This is more efficient than pretending the first attempt will succeed and then scrambling to redesign under pressure.
## Brooks's Later Reconsideration
In the 20th anniversary edition of *The Mythical Man-Month* (1995), Brooks partially recanted this advice. He acknowledged that the framing was too binary: you don't necessarily need to throw the *entire* system away. Instead, Brooks endorsed **incremental development** and **iterative approaches** as better models. Rather than building a complete system, throwing it away, and building another complete system, you build the system in small increments, learning and adjusting as you go.
Brooks noted that prototyping, iterative development, and what we now call agile methodologies provide a more nuanced and practical way to incorporate learning into the development process without the waste of discarding an entire system.
## The Underlying Insight
Regardless of whether you literally throw a system away, the deeper insight remains valid: **learning is inherent to software development**. You will discover things during implementation that you could not have known during planning. The cost of changing your mind grows with time, so the sooner you learn, the cheaper the changes.
This insight manifests in many modern practices:
- **Prototyping**: Building quick, disposable versions to test assumptions before committing to a design.
- **Minimum Viable Products (MVPs)**: Releasing the smallest useful version to learn from real user behavior.
- **Spike Solutions**: In agile development, building a quick throwaway implementation to explore a technical question.
- **The Lean Startup's Build-Measure-Learn Cycle**: Systematically building small experiments to validate hypotheses about what customers want.
## When to Apply This Thinking
The principle is most valuable when facing genuine uncertainty: new problem domains, novel technologies, unfamiliar user populations, or unprecedented scale. In these situations, planning for iteration is not pessimism but realism. Conversely, when building well-understood systems with established patterns, the need to "throw one away" is reduced because prior knowledge substitutes for the learning that a pilot system would provide.
## Relationship to Modern Software Practices
Modern software development has largely internalized this lesson, even if practitioners don't always trace it back to Brooks. Continuous integration, continuous deployment, feature flags, A/B testing, and the entire agile movement all reflect the understanding that software development is a process of discovery, not just construction. The question is no longer whether to plan for learning, but how to structure the learning process most efficiently.