# Topic 13 - 15
###### tags: `The Pragmatic Programmer`
### Topic 13 Prototypes and Post-it Notes
> Many industries use prototypes to try out specific ideas.
> -> Is musch cheaper than full-scale production.
- e.g. a new car design 🚗
- test in: aerodynamics, styling, structure...
- prototype by: use a clay modal, modeling in computer or virtual.
- why: **risky** or **uncertain elements** can be tried out without committing to building the real item.

#### :star2: We build software prototypes in the same fasion/reason:
- ==To analyze and expose risk==
- ==To offer chances for correction at a greatly reduced cost==
- We can target a prototype to test one or more specific aspects of a project

#### How to prototype?
- code-based(but not always have to be 🙃)
- Post-it notes(great for dynamic things: work flow, application logic) [Figma jam](https://www.figma.com/figjam/)
- whiteboard...


#### :star2: The core of prototypes
> Prototyping is **a learning experience**. Its value lies not in the code produced, but in the lessons learned.
:::success
- **much cheaper**
- **faster to develop** (than production)
- **can ignore unimportant details** (at this moment)
- no UI
- incorrect results or data
:::
#### Things to prototype
> Almost everythings 👻
- Anything **unproven**, **experimental**, **doubtful**
- Anything **uncomfortable with**
- Architecture
- New functionality in an existing system
- Structure or contents of external data
- Third-party tools or components
- Performance issues
- User interface design

#### What details can you ignore in prototype?
> Prototype gloss over details
- **correctness**
- **completeness**
- **robustness**
- **style**

*[Scripting languages](https://zh.wikipedia.org/zh-tw/%E8%84%9A%E6%9C%AC%E8%AF%AD%E8%A8%80)* also work well as the “glue’’ to combine lowlevel pieces into new combinations. Using this approach, you can rapidly assemble existing components into new configurations to see how things work.

:::danger
:name_badge: **Before enbark on any code-based prototyped:**
**MAKE SURE** everyone understand you are writing **DISPOSABLE** code!!!
:::

### Topic 14 Domain Language
> Computer languages influence how you think about a problem, and how you think about communicating.

| | Internal languages | External languages |
| -------- | -------- | -------- |
| 👍 | can take advantage of it's host language | can write a parser by yourself or others (JSON, YAML) |
| 👍 | is more powerful | |
| 👎🏽 | bound by the syntax and semantics | |

:::info
:star2: **Don’t spend more effort than you save**
In general, use off-the-shelf external languages (such as YAML, JSON, or CSV) if you can. If not, look at internal languages.
:::

### Topic 15 Estimating
> **having an intuitive** feel for the magnitudes of things, you will be able to show an apparent magical ability to determine their feasibility.
#### How accurate is accurate enough?
> To some extent, all answers are estimates.

**The units make a difference in the interpretation of the result:**
- 130 working days >>> 6 months

#### Where do estimate come from?
> All estimates are based on models of the problem

==**Ask someone who’s already done it**==
1. Building an understanding of what’s being asked
2. Build a Model of the System --> PoC
3. Break the modal into components --> Breakdown
4. Give each parameter a value
5. Calculate the answers
6. Keep track of your estimating prowess(next will'll be better 🙂)

#### Estimating project schedules
>
- Painting the missile
- The Program Evaluation Review Technique (**PERT**)
- has **an optimistic** and **a pessimistic estimate**
- **padding a number** for uncertain things

:::info
However, the only way to determine the timetable for a project is by **gaining experience on that same project 🐘**
- Check requirements
- Analyze risk (and prioritize riskiest items earlier)
- Design, implement, integrate
- Validate with the users
:::

#### Iterate the Schedule with the Code
This may not be popular with management, who typically want a single, hard-and-fast number before the project even starts.

You’ll have to help them understand(will determine the schedule):
- the team
- their productivity
- the environment

By formalizing this, and refining the schedule as part of each iteration, you’ll be giving them the most accurate scheduling estimates you can.


saying “**I’ll get back to you.**”
You almost always get better results if you **slow the process down** and **spend some time going through the steps we describe in this section**.