Skip to content

Latest commit

 

History

History
41 lines (33 loc) · 1.69 KB

katas.md

File metadata and controls

41 lines (33 loc) · 1.69 KB
Raw

Architectural Katas

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!

Ideas

See katas_ideas.md to have some more details

  • DocumentFactory
  • 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