I have compiled a list of things that I do when i review Golang code at work and I have published them in my Github account. Hope you find them useful!

# clean code

# Clean code and software estimation

StandardI just finished reading the Clean Code book, from Uncle Bob (@).

One of the chapters that was more interesting to me was the one about **software estimation**. That's because i think estimation is hard and is something that i want to improve upon.

#### Some general observations from Uncle Bob about software estimation

- simplest but most frightening activity that we software professionals face.
- bussiness value and developer reputation depend much on it.
- it's the main cause of opposition in the bussiness-development relationship.
- developers view estimates as guesses, bussiness as commitments.

#### Commitment

- is about certainty, and professionals shouldn't make one unless they know they can achieve it.
- missing one hurts developer's reputation and bussiness cost.

#### Estimation

- is a guess, no commitment implied: missing one is not dishonorable.
- most developers are terrible estimators because they don't know that the nature of an estimation is a distribution, not a number.
- the probability distribution of finishing a task can be seen as a graph where the X axis is the unit of times to complete it and the Y axis is the probability to finish it in those units:

- To minimize the uncertainty a developer may be asked for a commitment. Giving it explicity or implicity without certainty is a mistake and is not professional. Remember,
*"do, or do not. There is no try"*-- Master Yoda.

#### Estimation techniques

##### Three Point Estimation

- The Three Point Estimation (based on PERT) is a 3-point estimation technique where the points are the Optimistic Estimate (O) or best case, the Nominal Estimate (N) or greatest chance of success case and the Pessimistic Estimate (P) or worse case.
- The probability of distribution of the expected duration of a task is described as . Basically this formula gives 4 times more importance to the nominal estimate than the best and worst cases and does an average. The uncertainty of this task is mesured as the standard deviation .
- For a serie of tasks we have that and

##### Consensus Estimation

- Wideband Delphi: the team assemble, discuss, estimate the task and iterates until agreement.
- Flying Fingers: Wideband Delphi alternative where tasks are estimated on at time, each participant put their hands below and raise it at the same time from a cost estimation of 0 to 5 units (fingers)
- Planning Poker or Scrum Poker: similar to Flying Fingers but the units are chosen from a deck of cards. The units normally use the Fibonacci sequence (1, 2, 3, 5, 8) are sometimes are equivalent to man-hours of work. If you don't want to buy the card deck you can use mobile apps like these ones.
- Affinity Estimation: the card tasks are put randomly in the table and the team members sort the cards into unit cost piles without talking, the cards that are moved more than X times are discussed afterwards.

##### Consensus + Three Point Estimation

The team reaches a consensus based on the previous techniques but there are three estimates (O, N, P) and a probabilistic distribution is created for each task.

#### Conclusions

As a software developer you should know that an estimation is a guess, and to do it accurately is a hard task. If you estimate alone do a 3-point estimation, otherwise reach a consensus with your team using e.g planning poker (if you do Scrum this fits well in the backlog estimation meeting). Do not make a commitment to any task time unless you know 100% that you can achieve it. If a manager puts pressure on you to make a commitment negotiate first which task parts are going to be in and which ones out.