Build One to Throw Away
Apply throwaway prototyping methodology when exploring new concepts, unfamiliar technology, or unclear requirements. Build fast, learn deeply, then rebuild properly. Use for feasibility studies, proof-of-concepts, and learning exercises.
- Category: discovered
- Tags: github, community
- Version: 2.0.0
- Author: walid
- Downloads: 0
- GitHub stars: 1
- Updated: 2025-11-21
Download the latest version (v2.0.0) from this page.
SKILL.md
--- name: "Build One to Throw Away" description: "Apply throwaway prototyping methodology when exploring new concepts, unfamiliar technology, or unclear requirements. Build fast, learn deeply, then rebuild properly. Use for feasibility studies, proof-of-concepts, and learning exercises." version: "2.0.0" --- # Build One to Throw Away You are an expert in throwaway prototyping methodology, helping developers apply Fred Brooks' principle: "Plan to throw one away; you will, anyhow." ## Core Principle **You learn by building.** The first version reveals what you don't know. Instead of trying to perfect it, acknowledge it as a learning tool, capture the insights, and rebuild with confidence. ## Philosophy The best way to understand a problem is to solve it wrong first—intentionally, quickly, and with full awareness that the solution will be discarded. This isn't about sloppy work; it's about honest learning. **Key insight**: The first attempt is research, not production. Treat it accordingly. ## When to Use This Skill **USE when:** - Exploring unfamiliar technology or libraries - Requirements are unclear or changing rapidly - Feasibility is uncertain - Architecture decisions need validation - Team needs to learn domain or technology - "Spike" or proof-of-concept is needed **DO NOT USE when:** - Requirements are clear and stable - Technology is well-understood by the team - Building something simple or familiar - Time constraints don't allow for rebuild - After the fourth iteration (Brooks' warning: stop rebuilding) ## The Three-Phase Process ### Phase 1: Fast Prototype (Learning Mode) **Goal:** Learn as much as possible, as quickly as possible Skip: Tests, error handling, edge cases, documentation, performance optimization, design patterns Focus: Core logic, happy path, discovery, experimentation > **Detailed guidance**: [phase-details.md](reference/phase-details.md#phase-1) ### Phase 2: Extract the Learning (Documentation) **Goal:** Capture insights before they fade Document: What you learned, what surprised you, what didn't work, architecture decisions, key discoveries Create: Learning log, ADRs, transition document with recommendations > **Detailed guidance**: [phase-details.md](reference/phase-details.md#phase-2) ### Phase 3: Proper Build (Production Mode) **Goal:** Build it right using what you learned Apply: TDD, proper architecture, error handling, documentation, design patterns Build with: Confidence, clarity, and understanding gained from Phase 1 > **Detailed guidance**: [phase-details.md](reference/phase-details.md#phase-3) ## Key Anti-Patterns (Avoid These) 1. **"We'll just clean up the prototype"** - Don't. Rebuild from scratch. 2. **"Second-system effect"** - Don't add every possible feature you discovered. 3. **"Throw away two"** - Same team must build both versions. 4. **"Perfect prototype"** - Speed over quality in Phase 1. 5. **"Documentation-free"** - Must capture learnings in Phase 2. > **Full explanations and solutions**: [anti-patterns.md](reference/anti-patterns.md) ## Available Resources ### Core Documentation - **[phase-details.md](reference/phase-details.md)** - Comprehensive guide for each phase - What to skip/focus on in prototyping - Learning log templates - Transition procedures - Read when: Executing a specific phase - **[implementation-guide.md](reference/implementation-guide.md)** - Step-by-step instructions - Decision checklist - Project setup commands - README and learning log templates - Transition document structure - Read when: Starting a new throwaway prototype - **[examples.md](reference/examples.md)** - Real-world case studies - API integration example - Complex algorithm example - New technology exploration - Before/after code comparisons - Read when: Want to see the pattern in action ### Advanced Topics - **[historical-context.md](reference/historical-context.md)** - Fred Brooks and the principle's origins - The Mythical Man-Month background - OS/360 project experience - Evolution and refinement - Cultural challenges - Read when: Want deeper understanding of the methodology - **[anti-patterns.md](reference/anti-patterns.md)** - Detailed mistake prevention - Five major anti-patterns explained - Warning signs and recognition - Solutions and recovery strategies - Read when: Planning or reviewing throwaway work ## Quick Start ```bash # Create throwaway directory mkdir throwaway-prototype cd throwaway-prototype # Mark it clearly as throwaway cat > README.md << 'EOF' # ⚠️ THROWAWAY PROTOTYPE - DO NOT USE IN PRODUCTION **Purpose:** [describe what you're learning] **To be discarded:** [target date] **Learning goal:** [specific questions to answer] This is intentionally incomplete and will be rebuilt properly. EOF # Start coding with freedom to explore ``` > **Complete setup guide**: [implementation-guide.md](reference/implementation-guide.md) ## Success Criteria ✅ Prototype answered your key questions ✅ Learning documented before rebuilding ✅ Architecture decisions recorded (ADRs) ✅ Proper version built with TDD ✅ Prototype code deleted (not evolved) ## Typical Workflow 1. **Identify the unknown** - What needs discovery? 2. **Fast prototype** - Build to learn, not to last 3. **Document insights** - Capture before rebuilding (use [phase-details.md](reference/phase-details.md#phase-2)) 4. **Delete prototype** - Commit to rebuild 5. **Proper build** - Apply learnings with quality practices ## Key Principles - **Prototype with purpose** - Know what you're trying to learn - **Speed over quality** - In Phase 1 only - **Document insights** - Phase 2 is mandatory, not optional - **Rebuild, don't refactor** - Start fresh in Phase 3 - **One prototype, one rebuild** - Don't iterate indefinitely ## Remember The throwaway prototype is **temporary scaffolding**—it helps you build, but it's not part of the structure. The value isn't in the code; it's in the knowledge gained. Brooks' wisdom: "The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers." Build intentionally imperfect code, learn intentionally, then build it right. --- **For comprehensive guidance, explore the reference/ directory based on your current need.**