# TDD | Building Guide

When you need to make software with a lots of cyclomatic complexity and few surprises.

- **Assemble a coalition**. Don't work in a vacuum.
- *Decision-maker*: Drives during meetings, makes the tough calls and synthesizes the best ideas. Respect their rule.
- *Client*: Create clarity and understanding around why this is important, and what is expected, especially in edge-cases and non-standard scenarios.
- *Designer*: "Start with the user-experience and work back to the technology".
- *Engineer*: Find somebody else who is familiar with the code base that you're working in to bounce ideas off of.
- **Set aside robust period for architecting**. Design shallow, before building deep. Don’t waste time climbing the wrong mountain. It’s easy to make massive changes during design phase--much harder after it’s already built.
- **Draft blueprints**: work back and forth between design and [scenarios](https://docs.google.com/spreadsheets/d/1la5KEDFjUmYw3Mm-ITsyvBwedR-ACACD24VZ8iBcMWw/edit#gid=0) to develop [pseudo-code](https://hackmd.io/EOf-01GiTsaDVqKGQ2aw3w).
- Invite coalition to **feedback session**:
- **Decision-maker**’s **presents their ideas**, drives and creates. The rest of the group’s role is to serve decision-maker by providing clarity, ideas and socratic questioning/challenging.
- Have **humility**. Nobody gets to “pull rank.”
- Continue to **build understanding and consensus** between the group and iterate on scenarios and pseudo-code.
- Help make the best work possible: **think up uncomfortable and twisted scenarios** and “what ifs." Poke holes in the idea that something is simple. Articulate the implicit. Run through these scenarios with the client and assembled coalition and get consensus on exactly to expect under these conditions.
- Update **pseudo-code/DB design**. Pay attention to method names and signatures but don’t get overly detailed.
- **Iterate** until the iteration stops producing changes to the pseudo-code and no-one can think up any more scenarios.
- **Don’t rush** this part!
- Once there is consensus on how the app should behave under every scenario, turn the scenarios into tests and **develop** the pseudo-code into real code.