Who has never been stuck in design decisions that made the project slow down, sometimes to a halt?
We don't get to create full architectures from scratch often. Most senior architects have only seen a handful projects from conception to completion. Experience comes from errors, so I believe the best lessons come from early bad decision coming back to bite you.
We should practice "Architectural Katas" and (kindly) criticize each other, even beyond the technical points. What are the assumptions? Where is the customer most likely to change his mind? We need to share our insights to help balance between under-design and over-designing things.
Let's practice together!
See katas_ideas.md to have some more details
- Boardgames' lobby
- Strategy game
- Airport certifications
How it works
Of course, any rule can be change if the attendees reach a consensus.
Setting things up (15mn)
- we choose a "customer" and maybe a project
- the attendees form groups around 2/5 people
- the customer does a short brief (I'll have ideas ready)
Phase one (~30mn)
- you should ask the customer questions about the project
- define an architecture with your group
- any technology is OK if you justify its use
- any assumption is OK if you state it clearly (eg. don't know if technology X does Y? Say so and use it)
Presentations (20mn per group)
- your group will present the architecture (any number of speakers is fine: splitting the time is kind but difficult)
- the other groups are to ask questions and challenges hypotheses
- don't blame people, just say if something won't work and why
- you do not have hiring/firing authority over the development team