gabrielmoreira Overview
The biggest risk in software development is building a lot of code that doesn't work. Incremental coding limits this risk: build a little, verify it works, build more. At every step, the system is in a known-good state.
When to Use
- Any implementation that will take more than 2 hours
- When building in a complex domain you're uncertain about
- When multiple components need to integrate
Process
Step 1: Define the First Increment
- What is the smallest possible thing you can build that provides value and can be verified?
- It doesn't have to be feature-complete — just correct and verifiable.
- Example: "Add the endpoint skeleton with hardcoded response" before adding business logic.
Verify: The first increment can be verified in under 5 minutes.
Step 2: Build → Verify → Commit
- Build only the first increment.
- Run tests. Verify manually if needed. Confirm it works.
- Commit this working state.
- Repeat for the next increment.
Verify: There is a working commit after each increment.
Step 3: Integration Continuously
- Integrate with the real system as early as possible — not at the end.
- Test against real dependencies (DB, API, etc.) as early as possible.
- Fake integrations (mocks) should be replaced with real ones by the end.
Verify: By completion, all mocks replaced with real integration.
Common Rationalizations (and Rebuttals)
| Excuse | Rebuttal |
|---|---|
| "I need to build it all to know if it works" | No. Build the first piece and test it. Uncertainty is always reducible. |
| "Integration is at the end" | Integration pain is proportional to time since last integration. Integrate continuously. |
Verification
- Implementation built in verifiable increments
- Working commit exists after each increment
- No long stretches of "broken" state in git history
- All mocks replaced with real integrations by completion