In 30 seconds
- Design evolves with the code, guided by tests and refactoring.
- Decide big things only when you have enough information.
- Needs discipline: refactoring and simple design every day.
How it works
Rather than designing everything before coding, the team builds the simplest thing that works, then improves the design as new needs appear. TDD and refactoring are the main tools.
What it needs
- Strong automated tests
- Daily refactoring
- Simple design rules
- Willingness to change earlier decisions
Balancing with architecture
Pure emergence can struggle with system-wide concerns like security or scale. Many teams combine it with a light, intentional architecture: decide what's expensive to change early, and let the rest emerge. See agile architect.
Myth vs reality
Myth · Emergent design means no design.
Reality · It means continuous design.
Myth · It works without refactoring.
Reality · Without refactoring, emergent design becomes a mess.
Myth · Architecture is never planned.
Reality · Costly-to-change decisions still need thought.
FAQ
What's the last responsible moment?
Deciding as late as possible without the delay itself causing harm.
Does emergent design suit large systems?
With intentional architecture for the big pieces, yes.
How do we know design is improving?
Changes get easier, not harder, over time.