> For the complete documentation index, see [llms.txt](https://yoan-thirion.gitbook.io/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/practices/design-sessions.md).

# Design sessions

A technic to better design solutions in a collaborative way

When I was fully in Dev Teams it is a practice we used to define the implementations of our features. It consists in brainstorming and aligning at the beginning of each feature implementation.

### How to ?

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKddILFfduwRcdXHt2Y%2Fimage.png?alt=media\&token=2b4546fb-6727-4959-bdb0-f5a68c52ee68)

Once a team member wants to open a new Product Backlog Item, User Story or feature implementation, we do an instant meeting in front of a whiteboard and a computer.

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKde1yWx98qImgQS36F%2Fimage.png?alt=media\&token=c0777eb8-fa8a-4063-b1d5-4f9bed9a320f)

* We start by agreeing on its definition
* Be sure we are all aligned on what needs to be done

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKdeJsEAYXH3ms3hq4-%2Fimage.png?alt=media\&token=60a388e6-5a23-4b80-a57a-4c0cec17fbcf)

We use the whiteboard to align ourselves on the different flows to implement

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKdecZMOV4Ghq97bwmR%2Fimage.png?alt=media\&token=1d1b6108-7b41-470d-b961-1f6ab7d947a6)

* We open the source code or create a new one and start designing the contracts :
  * From our external layers (APIs for example) to our Domain model
  * POCOs / POJOs
  * DTOs / Commands
* We don't implement anything except of the contracts
  * We throw exceptions `throw new NotImplementedException()`
* BUT we agree on the naming / parameters
  * We put TODOs in the code to be clear what is expected to implement
  * Later on I have learned that this TODO approach to implementation had a name : [Puzzle Driven Development](https://www.yegor256.com/2010/03/04/pdd.html)

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKdeoCO34bmGwnKFhDm%2Fimage.png?alt=media\&token=31a58a96-3e9d-4e6c-8b85-c52c71718da2)

The whole team or part of it can now work on the implementation by knowing exactly what to do.

### Pros

* Instant alignment feedback on what needs to be done
* Increased knowledge sharing
  * Quick up-skilling for new-joiners
* Better solution when designed collaboratively
  * "Alone we go faster together we go further"
* Save a lot of times
  * Avoid feedback loops (in code reviews for example) when no team alignment
* Reinforce the collective ownership feeling inside the team
* Help to shape a real team spirit as well
  * Everyone is involved at the beginning of everything

### Infography

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MKdZoCuGt233J0AaZ4M%2F-MKdaqQcCCDQQ4fZ2xC8%2Fimage.png?alt=media\&token=8bf00d62-506a-4048-870f-ac985cc4017c)