---
# System prepended metadata

title: Topic 13 - 15
tags: [The Pragmatic Programmer]

---

# 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...

![](https://i.imgur.com/Nu1eQdB.jpg)

#### :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:**
![](https://i.imgur.com/n95oJGk.jpg)
- 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. 


![](https://i.imgur.com/DGO0ky7.png)

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**.
