TL;DR: Software projects usually fail for one simple reason: design committees and Jira backlogs replace actual working software. Prototyping in the first 48 hours forces real-world physical and architectural constraints into view immediately. Build throwaway code to test the hardest questions first, harvest the parts that work, and build production architecture on proven ground.
┌────────────────────────────────────────────────────────────────────────┐
│ TWO SOFTWARE INCEPTION CULTURES │
├───────────────────────────────────┬────────────────────────────────────┤
│ THE DESIGN COMMITTEE LOOP │ THE BUILD + HARVEST LOOP │
├───────────────────────────────────┼────────────────────────────────────┤
│ • Weeks of Figma wireframing │ • 48-hour interactive prototype │
│ • Exhaustive Jira ticket planning │ • Tests real physics & API latency │
│ • First code written in month two │ • Collides with reality on day two │
│ • Discovers hard bugs at launch │ • Drops failed ideas for $0 risk │
│ • Painful late architectural cuts │ • Harvests proven code to prod │
└───────────────────────────────────┴────────────────────────────────────┘
Every software team starts a project in one of two distinct inception cultures:
- Design + Process Only: Months of design sprints, wireframing workshops, backlog grooming, and specification documents before a single line of working code runs.
- Build + Harvest: Rapid interactive prototyping to test real physics, data shapes, and user mechanics, harvesting what works into production architecture.
Both cultures claim to reduce risk. Only one actually does.
The Illusion of Spec Certainty
The design-first culture operates on an unspoken assumption: that software problems can be completely understood from the outside before you build them.
Teams produce beautiful 100-page Figma decks and exhaustive Jira tickets. Everyone feels productive because the artifacts look polished. But the moment real engineering begins, reality pushes back:
- The third-party API has latency spikes that destroy the smooth animation you designed.
- The mobile OS aggressively terminates background sync jobs you relied on.
- The state management model that looked clean on paper creates subtle race conditions under real network jitter.
Because no real code was tested early, the architecture must be compromised during crunch time. The team spends twice as long rewriting features under pressure.
The Build + Harvest Loop
Build and harvest takes the opposite approach. When an idea emerges, the team builds a throwaway prototype in 48 hours.
The prototype is not meant to be clean. Its entire job is to collide with the hard realities of the platform:
- Can this shader run at 60 FPS on a mid-range phone?
- Does this data structure fit cleanly into local storage?
- Does the core interaction actually feel fun or responsive in the hands of a human?
Once the prototype proves the core mechanic works, you harvest:
- You take the working mathematical formulas, state transitions, and shaders.
- You throw away the messy glue code.
- You build the real product on solid ground with known constraints.
Culture Comparison Matrix
| Dimension | Design + Process Only | Build + Harvest |
|---|---|---|
| First Working Demo | 6 to 12 weeks into project | 48 to 72 hours after inception |
| Cost of Discarded Idea | Weeks of meeting time & morale | Two days of throwaway code |
| Architectural Discovery | Papered over until implementation | Surfaced immediately by compilers & hardware |
| Team Atmosphere | Bureaucratic gatekeeping | High agency, playful momentum |
| Primary Output Metric | Story points closed on board | Working software running on real devices |
The 3-Step Harvest Rule
If you are starting a new feature or project this week, try this operational sequence:
- Build the toy: Build the simplest interactive version of the feature that proves or disproves the riskiest hypothesis. Hardcode every value. Ignore unit tests.
- Stress-test the toy: Run it on the worst hardware you support. Throw bad network latency at it. Pass it to a team member with zero instructions.
- Harvest and construct: Open a clean branch. Copy the core algorithmic logic and math. Throw away the scaffold. Build the permanent architecture with confidence.
Build first. Collide with reality quickly. Harvest what survives.
References, Standards & Verified Data
- The Pilot System Rule: Fred Brooks, The Mythical Man-Month (Addison-Wesley, 1975), Chapter 11: "Plan to throw one away; you will, anyhow." Discusses why the first version of any novel software architecture serves primarily to uncover unstated physical and platform assumptions.
- The Agile Manifesto Core Tenet: Kent Beck et al., Manifesto for Agile Software Development (2001) - "Working software over comprehensive documentation" and Principle 7: "Working software is the primary measure of progress."
- Lockheed Skunk Works Prototyping Rules: Clarence "Kelly" Johnson, Kelly: More Than My Share of It All (Smithsonian, 1985) - Rule 3 and Rule 8: Restricting administrative staff, colocating engineers with hardware, and validating flying physical prototypes within 90 days.
- Strategic vs Tactical Software Design: John Ousterhout, A Philosophy of Software Design (Yaknyam Press, 2018) - Outlines how working prototype iterations surface interface complexity early before it gets baked into permanent class hierarchies.