Clean code and software estimation
I 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.
- 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.
- 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.
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
- 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.